I am not sure of the universality of the remark that Richard makes about the
inability of products that precompile a DTD to process the parameter
entities that define marked sections that effect "switches" such as turning
on or off XML vs SGML output or the table v. non-table functionality in EAD.
I have worked with both WordPefect2000 and XMetaL which have compiled the
DTD with the XML "switch" set and have had no apparent problems.
Head of Processing
Minnesota Historical Society
345 Kellogg Blvd West
St. Paul MN 55102-1906
[log in to unmask]
**NOTE NEW AREA CODE EFFECTIVE JULY 12, 1998**
> From: Richard Higgins[SMTP:[log in to unmask]]
> Sent: Wednesday, June 09, 1999 3:25 AM
> To: Multiple recipients of list EAD
> Subject: Re: Compiled DTD applications and EAD's alternative drow/did
> 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
> > 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
> > >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
> > >alternate drow structure. This could either be optional, if all you
> > >using is the drow structure, or necessary if you are as unfortunate as
> > >am and use both drow and did.
> > >
> > >Unless of course anyone has a simpler solution ...
> > >--
> > >Richard Higgins
> > >Durham University Library