Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <email@example.com>
- Date: Fri, 22 May 98 15:15:07 UT
>If I understand this correctly, then you are saying that at first you
>allow no extensions, just as DTDs allow no extensions.
DTDs aren't allowed to change document syntax - the use of tags for elements
and attributes, the use of '&' for general entities, etc. The same rules
apply in this representation, as I will state more explicitly. This
representation would, however, allow _additional_ rules - with data schemas
the first issue to be addressed. This really isn't that difficult.
>Is there any good reason that the ability to change the parse tree should
>be conflated with the responsibility for verifying schema-compliance as
>they are in DTDs. Is there any good reason to perpetuate this conflation
>in your proposed replacement for DTDs?
I'd like to see a structure that's:
a) easily interpreted, edited, and stored, without the need for multiple
b) capable of containing a complete set of information about a document,
including structure and data
What's so difficult about that? I can't think of any good reason (besides
SGML compatibility) to oppose either of those goals. Why on earth would I
want to keep multiple sets of document descriptions (schemas, whatever) around
that share the task of defining the same document set? It seems like a
management mess, a processing mess, a waste of bandwidth and storage because
of redundant information, and just generally a nuisance.
Making DTDs extensible is a good way, in my view, to address this issue, and
Dynamic HTML: A Primer / XML: A Primer / Cookies
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)