[
Lists Home |
Date Index |
Thread Index
]
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <xml-dev@ic.ac.uk>
- Date: Wed, 27 May 98 22:12:47 UT
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@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)
|