Re: DTD Fragments and XML

I know this is an old thread (and the topic has pretty much been carried
over to SD-5), but FWIW...

At 04:28 PM 5/3/97 -0400, Paul Prescod wrote:
>Terry Allen wrote:
>> This is not Paul's main concern in this post.  To set the record straight,
>> for Docbook you would construct a customization layer consisting of
>> additional overriding parameter entities and associated stuff.  You
>> wouldn't have to touch the DTD for most purposes.  However, Docbook's
>> means of achieving this uses empty parameter entities, which I now
>> understand to be invalid in XML.  I'll spend part of this weekend
>> removing them from my XMLized version of 3.0, which is now called
>> XDB 0.2 (available at http://www.sonic.net/~tallen/xdb02.zip).
>> I'd welcome correction on this point, or suggestions for other
>> methods of customization that are valid in XML.
>
>Even if you get it working, I don't consider modifying parameter
>entities and rewriting content models is a very easy way to add a single
>element to a DTD. Inclusions may be evil in SGML, but the XML
>alternative "just delete that DOCTYPE thing" seems worse to me.

It's hard to add a line to your internal subset that says this?

<!ENTITY % local.list.class "| MyList">

>As far as future-SGML goes, I'm thinking that it should be possible to 
>
> * extend the content model of an element whose existing content model
>is a simple or-group, 

If we solve the problem of empty parameter entities, this one is eminently
achievable in XML, based on the experience of parameterized DTDs such as
DocBook.  In SGML, this is already easy.

> * override an entity in a way that depends on the old entity,

This is tougher.  DocBook had to go to a lot of trouble to allow the
redefining of "mixture" entities by referencing "class" entities, and while
it's possible, it's not easy to understand.  Actually overriding *parts* of
a *single* entity while preserving some of its content is impossible.

> * (perhaps) prepend and append contents to a content model.

Generally achievable if you parameterize the (null) beginning, body, and
(null) end and combine all into a bigger entity.

> * include content in some form of namespace.

Not sure what this means.

>But for XML I guess I would be happy with a standard syntax for
>declaring the namespace that your elements come from:
>
><?XML-TAGSET TEI PUBLIC "-//TEI//DTD TEI Lite 1.0//EN"?>
>
>You could "combine" DTDs by tagset-including more than one DTD. GI clash
>will be a problem, but a solvable one. GI clash wil only be a problem
>for the elements you actually use.

This is precisely what is done by incorporating common DTD fragments such
as CALS tables.  GI clashes can be solved by parameterizing GIs.

One of the messier problems with this is managing recursive dependencies;
for example, table cells eventually have to contain some of the contents
that the rest of your DTD allows, like paragraphs or whatever.  But with
the right kind of parameterization, this is done all the time today in SGML.

>For this to be meaningful, there would have to be a conformance level 
>between well-formedness and validity. We would advocate (or even 
>require) that XML documents live in the upper two levels. 
>
>I hope I've demonstrated that the space between well-formedness and 
>validity is HUGE and that we will lose big if we force authors to 
>choose between flexibility/accurate generic markup and declared 
>gi-semantic conformance to standard DTDs.
>
> Paul Prescod

The existing XML comes pretty close to the requirements you've stated.  The
burden is on the original DTD (or DTD fragment) designer to parameterize
the markup model properly; the user needs to know a couple of tricks in
order to customize the DTD(s), but can come out the other side with a quite
usable DTD that they can validate against.  What XML can't do (yet?) is
have different ID or GI namespaces.

Regardless of whether/how we attack the namespace problem, it's sure
sounding to me like we need parameter entities that are maximally flexible,
which the current spec doesn't give us.  I don't know if the PE design can
be changed for 1.0, though.

	Eve

Received on Wednesday, 21 May 1997 17:35:44 UTC