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