xml-dev - RE: Proposal Announcement - XML DTDs to XML docs

["Simon St.Laurent" <SimonStL@classic.msn.com>]

It's good to get feedback.

Paul Prescod stated:
>Another problem is "specification encapsulation." XML 1.0 is specifically
>designed NOT to depend on XLink or XPointer. Your proposal depends on
>them. It seems to me that there is some sort of circularity problem there.

I think this circularity problem is not too difficult to cope with in 
practice.  It could be reduced, if not disposed of, by decomposing XML 1.0 
into three different specs:

1) A document syntax specification (a simplified version of well-formed 
documents)
2) A syntax for linking to DTDs (and perhaps schemas) internal or external 
(which would depend on XLink)
3) A syntax for DTDs providing rules for validation.
(Schema definitions could rest on top of #3 or beside it.)

Even if these seems inadequate, I think it would be useful to reduce the 
number of ways users and developers reference external resources from XLinks, 
general entities, parameter entities, notations, and assorted other goodies to 
a single URI-based spec with consistent notation, preferably XLink.

>Nobody has ever done the work to flesh it out to the point where an
>XML-document notation is as expressive as the current DTD notation. I
>believe that people who have not been using the DTD notation for a long
>time underestimate the extent to which common use depends on weird stuff
>like parameter entities specifying partial content models, element types
>in element type declarations and so forth.

I realize that these are significant challenges, and that conversion to an XML 
document format for DTDs doesn't whisk them away.  What I'd like to see is a 
determined effort to map the 'weird stuff' to XML DTDs.  Note, for instance, 
that I kept the SGML-like content model in my examples.  It's sort of a 
half-way step, leaving in some of the old that the new may prosper.  As for 
parameter entities, I think they can be expressed as easily through the model 
I presented.  Fleshing this out is admittedly a large task that I don't think 
I can manage alone.

>A user interface
>(markup languages *are* user interfaces) can be too consistent, if it
>obscures the differences between things. In the case of documents and
>DTDs, I expect many users would get confused about the distinction between
>documents and DTDs if DTDs *were* documents.

This is a significant consideration I hadn't noticed, and I'll address it more 
directly in the next revision. I don't think it's insuperable.

>There is also the issue of compatibility. If the DTD for DTDs is
>extensible and open, as most proponents argue it should be, then
>Microsoft, Netscape and Sun can all take shots at "extending" it in the
>way that they "extended" HTML. If the DTD DTD was specifically designed to
>be extensible, then we could not complain about that. Depending on the
>level of extensibility, XML documents could actually parse differently
>depending on which browser you were using. If it was designed NOT to be
>extensible, then we have to cross one of the benefits of this alternate
>notation off of the list. 

I would certainly want this to be extensible; parsers that didn't understand 
an extended portion of this DTD could simply ignore that portion, provided the 
document met the basic rules.  I don't see this as a significant problem, 
especially after looking at several of the schemas other people are proposing 
for XML documents.  XML is going to fragment to a certain extent; I'd like to 
see the core made more extensible to provide an orderly framework for such 
extensions rather than letting them run off on their own.

>Several of my complaints about your proposal stem from the fact that DTDs
>both change the parse and validate the document. In other words, they are
>both schemata and "parse information providers". If your XML-instance DTDs
>only validated, then many of the complaints would go away. But if they
>only validated, I don't think it would be accurate to call them DTDs
>anymore. Then they would be just "schemas" since they would accomplish
>only one of the DTD's two functions.

I think you miss part of the point - that this is a representation intended to 
completely represent the same data that is provided currently by XML DTDs.  
You seem to assume that there will be data lost in the transition, without 
pointing out where it would be lost.  I think you could build the same schemas 
and parse information with this system as you could with the current XML DTD 
structure, while providing the extensibility that several other proposals seem 
to need.  I would rather _not_ provide full schema information in this 
proposal - moving XML DTDs to a new format seems like enough of a task to 
start with.

In the long run, of course, DTD would be an inadequate term to describe these.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)