Lists Home |
Date Index |
- From: "Matthew Gertner" <firstname.lastname@example.org>
- To: "XML Dev" <email@example.com>
- Date: Fri, 5 Jun 1998 19:06:17 +0200
>Question: Should entity support be provided in XSchema?
>The goals do not require entity support. During the goals process, a
>of people suggested staying out of the entity business, though a few also
>thought it was important. Both Ron and John have included entity support
This essentially boils down to a philosophical question: is XSchema mainly a
new XML-based syntax for working with DTDs or is it the start of a new
paradigm for working with XML. My strong preference would be for the latter,
including jettisoning baggage from SGML which was included in the XML spec
for compatibility reasons but which does not necessarily make sense for new
Seen in this light, I don't see any reason to include entities in XSchema.
Entities are really too powerful and including them as a native construct in
the schema makes a lot of infrastructure projects far more complicated (SAX,
DOM, etc., etc.). Part of the paradigm shift that I am hoping will take
place is a move away from entities and towards more structured linking
mechanisms (i.e. XLink and XPointer). This presupposes a certain number of
things that most of us seem to take for granted anyway, such as the fact
that graphical authoring environments will replace hand-coding of XML for
most non-trivial tasks. To this I would add mixing-and-matching of schemas;
entities are abused far too much because of this current lack.
The prospect of having an XML-based syntax that takes over the roll of the
DTD for defining schema information is very exciting because the prospects
for exploiting the synergies rising from this are enormous. It becomes even
more so if:
1) Parameter entities become reusable schema fragments (I hacked together an
example of this using XLink in a previous post),
2) General entities become XLinks, reducing the free-for-all flavor of XML
and enforcing structure.
3) Character entities become transparent to the author and consumer.
BTW: I feel the same way about notations. Why not leave them out in favor of
a real typing system to be added to the XSchema core sometime in the future?
Specifying some basis atomic types, a mechanism for defining structured
types (preferably based on reuse of schema fragments) and a tie-in to MIME
types surely wouldn't be a project of any more complexity that the basis
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)