I still don't understand the problem. We've used AdeptEditor
for many years. Compile your DTD with the tabular markup
switch to INCLUDE. You will be able to encode both tabular
and nontabular finding aids using just the one DTD. Adept
will validate both types of finding aids. Your sentence:
"compile two versions of the DTD, one for <did> the other
for <drow>" I think is misleading. It implies an either/or
situation, that if you compile the tabular version, <did>
is no longer available, but that's not true. It's true that
you cannot compile *two* DTDs with the same FPI but I guess
I'm unclear on why you cannot use just one DTD to encode both
types of finding aids. I'm very interested in this because I
personally don't want to have to deal with multiple DTDs and
Online Archive of California
[log in to unmask]
At 09:25 AM 6/9/99 +0100, you wrote:
>Yes - this works with applications that don't use a compiled DTD - it
>works here at least with Dynaweb and Dynatext, and parses with nsgmls.
>However, the problem is with products that precompile their DTDs, as
>Adept Editor does. While these are capable of picking up extra entities
>from the declaration subset, they cannot register switches of the
>INCLUDE/IGNORE type, so you are stuck with whichever way the switch was
>set when the DTD was compiled. The compiled DTD used on loading a
>document is set by the FPI alone, so while it would be possible to
>compile two versions of the DTD, one for <did> the other for <drow>,
>unless you can have two FPI's to distinguish them the editor will only
>ever use one of them.
>Alvin Pollock wrote:
>> We use both as well. I believe the non-tabular version of
>> the DTD is a simple subset of the tabular version. If you
>> set the following:
>> <!ENTITY % tabular 'INCLUDE' >
>> <!ENTITY % nontabular 'IGNORE' >
>> then you can do everything. You can continue to use the
>> <did> model and ignore the tabular elements altogether.
>> Both tabular and nontabular EAD documents will validate.
>> The only difference is that when you open a <c> your list
>> of available elements will include one additional element,
>> <drow>, otherwise the interface is identical for users
>> who do not use <drow>/<dentry>. We've never had a problem
>> creating or validating EAD documents of both types using
>> one DTD. I don't see a need for a separate FPI except that
>> then we would be forced to use two DTDs instead of the one
>> we are currently using. Am I missing something?
>> Alvin Pollock
>> Lead Programmer
>> Online Archive of California
>> [log in to unmask]
>> At 01:46 PM 6/8/99 +0100, you wrote:
>> >When the version 1 EAD DTD emerged, the means it used to express the
>> >tabular (drow)/non-tabular (did) structures was neatened up by the use
>> >of an INCLUDE / IGNORE switch in ead.dtd, controlling which of the
>> >structures was used.
>> >However, software which uses a precompiled DTD (such as EMACS and
>> >Arbortext's Adept Editor) which it loads on first reading the FPI does
>> >not register the subsequent reversing INCLUDE / IGNORE switches in the
>> >document type declaration subset. This means you can compile only one
>> >version of the DTD, so it is only possible to work with one structure.
>> >Which is fine until you need to use both. As the editor uses the FPI to
>> >select the compiled DTD, the only way to control this behaviour is to
>> >amend the FPI itself.
>> >While it is possible to have a batch script which can be run before and
>> >after editing, it seems reasonable to have a second FPI for use with the
>> >alternate drow structure. This could either be optional, if all you are
>> >using is the drow structure, or necessary if you are as unfortunate as I
>> >am and use both drow and did.
>> >Unless of course anyone has a simpler solution ...
>> >Richard Higgins
>> >Durham University Library