XSD: What will it do?

[Simon St.Laurent]

David Peterson asked:

>other than being in XML format, what do you want SDDs to be able
>to do that DTDs can't?  Documentation is an important one, but that doesn't
>help with the structure.

I think at this point, it's not so much about the structure - this is not a 
long-way-around way to restore the '&' operator or provide some kind of 
strange structure that's optimized for a particular processor.  Structurally, 
XSD is talking about doing less than DTD's do now, focusing on one part, 
describing element and attribute structures, and leaving out the rest of the 
toolbox.

Putting this information into SDDs that use XML syntax opens up several 
possibilities.  Initially I was intrigued by the idea of using tools 
consistently across the range of XML specs, and those ideas formed the core of 
my proposal at http://members.aol.com/simonstl/xml/xmldtd2doc.htm.  We've 
narrowed it down from this considerably - that proposal is now marked 
obsolete.   Other people participating in this project undoubtedly have 
different motivations, which they're welcome to describe.

What we're doing now is opening up element and attribute descriptions to allow 
the use of nested documentation and other descriptive information.  For now, 
we're focusing on creating the nested structure in which that descriptive 
information can live, not specifying too much of what that information should 
look like.  Your example shows one vision of what that might look like.

Hopefully, in addition to the convenience factor of using the same parser for 
SDDs as is used for XML documents, we're building a base - a core module - 
which other standards can use to extend the kinds of information used to 
describes elements and attributes.  There are many concerns about the kinds of 
extensions that this will make possible, but hopefully we can rein them in 
enough to make XML more powerful without making it brutally chaotic.

In its most stripped-down form, XSD may also provide application developers 
with a lightweight means to check element and attribute structures without 
needing to figure out parameter entities, external inclusions, and the other 
power tools which make processing a DTD more complex.   I'd like to see a 
simple tool that verifies a document against an XSD built as one of the early 
implementations, and I'm covering a whiteboard with my own odd ideas of how to 
accomplish this.

>And if it can do things DTDs cant, then you're
>always going to loose information when you translate to and from DTDs.

I think we've accepted this.  Element and attribute structures are going to be 
the only pieces of an SDD or a DTD that transfer back and forth.  DTDs don't 
handle extensions; SDDs don't handle entities.  Eventually a richer XSD 
standard (or a W3C standard that replaces it) might define more capabilities 
that bring a fuller DTD toolset to SDDs, but for right now, 'small is 
beautiful'.

>Should I eat rice bubbles or corn flakes in
>the morning?

That's difficult.  Personally, I like toast.

Simon St.Laurent
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;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)