Re: B.7 Conditional inclusion in DTDs?

At 07:14 PM 10/14/96 -0500, Len Bullard wrote:
>Charles F. Goldfarb wrote:
>> 
>> On Sat, 12 Oct 96 15:06:59 CDT, Michael Sperberg-McQueen
>> <U35395@UICVM.CC.UIC.EDU> wrote:
>> 
>> >On 16 October 1996, the ERB will vote to decide the following question.
>> >A straw poll indicates the question needs further discussion in the work
>> >group.
>> >
>> >B.7 How should XML deal with the need for conditional inclusion of
>> >markup declarations, if XML has no marked sections (10.4.1)?
>> 
>> XML shouldn't have conditional DTDs. They defeat the objective of simplicity.
>> Those who need complex DTD management will be using full SGML and can easily
>> generate XML from it.
>> --
>> Charles F. Goldfarb 
>
>Also concur.

As do I (I think).  Presenting DTDs to new XML users will be easier if
we constrain them (the DTDs :-) to single "state spaces" for now.

>I would personally like to see reduced complexity in 
>DTD design practice.  Right now, I am creating style sheets.
>The complexity of the conditional DTDs I am working with is absurd.
>Modularization by parameter entity, conditionals, inclusions, 
>exclusions, just to hit the obvious ones, make the state space 
>of these DTDs bigger than Pluto's Orbit.  While they are legal,
>they make any menu or dialog system generated from them almost
>worthless as a way to guide an author.  They would be much 
>better in production if broken up into multiple DTDs.  This 
>is a design habit I think XML can promote.  The next 
>generation of DTDs would not give one the uncomfortable 
>feeling of walking in the temples of ancient Mexico where 
>one can admire the intricacy, but despair at the blood shed 
>to stack rocks that high.  Authors are paying a high
>price for the convenience of DTD version management which 
>is really not that convenient and not done that often. The
>rate of change isn't that high. While not a technical 
>concern, promoting simplification for the sake of 
>effective production is a worthy goal.

As one of the perpetrators of outrageously parameterized DTDs,
I have to disagree.  Most DTDs don't need and shouldn't use 
parameterization on the level of a DocBook or TEI, but any DTD 
with a very diverse user base typically needs customization in 
order to be useful.  (Many more people cannibalize DocBook than 
use it out of the box.)

Since these audiences don't share any particular DTD management 
system, the ability to customize is needed in 8879 form.  And
maintenance truly is a nightmare if you're maintaining both your
changed portions and the original portions, which you need to do
whenever the base DTD gets an upgrade (as DTDs with huge audiences
tend to do regularly).  Plus, a DTD customization layer provides a
machine-readable (and relatively human-readable) specification of
precisely how your markup model differs from the base one.

DTD analysis tools are popular and available enough to help people
wend their way through forests of parameter entities, to the point
where DTD readability is much less of a concern (though I still feel 
that readability should be an important *secondary* goal of a raw DTD).

Finally, in any one "reading" of a parameterized DTD, the markup
model is stable; in my experience, authors pay no extra price for
DTDs that are parameterized.  In fact, the ability to rip out the
elements that are irrelevant to one's own situation has meant that
DocBook (for one) has become quite a bit *more* usable.

The management of SGML documents and associated tools (including
DTDs) is still in its infancy.  I believe in using the 8879 techniques
at my disposal until a portable, functional way of doing the same
thing arises.  Eventually, the XML user base should be let in on 
these methods as well (whatever they are at the time).

        Eve

Received on Tuesday, 15 October 1996 09:41:45 UTC