Proposal Critique - XML DTDs to XML docs
SimonStL at classic.msn.com
Fri May 22 23:26:43 BST 1998
I thought I was arguing with a conservative, but now I see that you're a
radical! Very impressive, and I think we're reaching some points where we (at
last) both agree.
> a) instance syntax
> b) textual replacement
> c) external text embedding
> d) extensible validation
>XML 1.0 incorporates all of them. I think that that made sense for XML
>1.0, in order to be SGML compatible, but for future versions I would
>rather see the first three completely separate from the fourth. The reason
>I feel that the last should be separated is that the types of validation
>(or "verification") that people have to do can be quite varied.
Actually, I'd like to see all four of these separated, except for b and c,
which I feel should at least use common syntax. a is the basic XML document
syntax, b and c provide entity and linking-type services, and d is today's
point of contention. Still, this breakdown of the standard is a very good
>the DTD optional for this reason. I don't see that making the XML
>specification substantially larger with an alternative encoding for DTDs
>can really make that specification simpler.
You're right here as well. I'd recommend disconnecting d, the validation,
from the core standard (which I really think is just a). Making validation a
separate standard would open the way a re-examination of validation that
wasn't deeply intertwined with existing syntax, and could well lead the way to
a syntax better than either the current standard or the XML document syntax.
At least it would keep the core standard from growing warts.
>I tend to think that a strategy that is more likely to be successful is
>one that layers schema languages. At the bottom level you have something
>like XML DTDs without all of the stuff related to entities and notations
>(in XML element notation). That layer might include data type validation.
>In levels above that you have RDF and other schemata that are more
>interested in relationships than in positional occurrence.
I'm very cautious right now about adding too many layers of schemas, mostly
because they seem to require very high levels of redundancy. (XML-Data, a
DTD, and an RDF representation of a single document? And they all have to
stay consistent? Whoa...) Still, a layered model like this might make sense
in the long run, provided that we can stay away from truckloads of redundant
>But if you try to make it a replacement for DTDs, then it must do
>everything that DTDs do and inherit all of the problems that the
>conflation of features in DTDs causes.
>The question is what is the right design. You can make a slightly
>better version of a bad design, or you can try to start again with a good
I fear this is a symptom of the conservatism of the proposal, which began
merely as an effort to map DTD syntax to an XML document syntax. It inherits
the warts along with the beauty. A more radical solution would excise many of
the warts, but didn't seem like a wise idea given the conservatism of many in
the XML community. Smaller steps on the way to a radical change seemed more
appropriate in this environment, but that may not be the best way to go.
>Does it make sense
>a) that textual substitutions should be specified in a part of a document
>called a "document type definition".
No. Entities were what bothered me most about XML DTDs in the first place.
I'd move them elsewhere quite happily.
>b) that the "document type definition" should also be responsible for
>declaring media types and attaching them to non-XML entities.
No. This seemed like a significant departure from current practice on the Web
(which I support strongly) - MIME types.
>c) that the language for verifying element and attribute occurrence must
>be in the same specification (XML 1.x) as that for creating elements and
Must be? No. Could be, and would offer significant advantages? Yes. I
still think XML document syntax has significant advantages over current
syntax. Could there be a better syntax? Of course.
>If we are to replace DTDs, let us replace them
>with something simpler and more specific to the task of validation,
>instead of transliterating them into another syntax, warts and all.
Good idea. Who, where, when? I'll buy beer...
I think I'll continue the proposal as an implications document, while looking
out for something more radical. In the meantime, I've got a lot of XML to
Dynamic HTML: A Primer / XML: A Primer / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev