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
http://sunsite2.berkeley.edu/oac
[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
>
>
|