Entities in XSchema - moving toward a processing model
SimonStL at classic.msn.com
Tue Jun 9 19:56:29 BST 1998
John Cowan wrote:
>Many, many XML-DEVers wrote, in effect:
>> Entities in XSchemas suck big ones.
Good... one less section to write, and a lot less to explain about processing.
>If, however, purely declarative information is to be removed from
>XSchemas, then I think that parts of the attribute-type and
>attribute-value declaration syntax should go. In particular,
>attribute types are reduced to Name (ID, IDREF, ENTITY, NOTATION),
>Names (IDREFS, ENTITIES, NOTATIONS), Nmtoken, Nmtokens, and CData;
>attribute values are reduced to #REQUIRED, #FIXED "foo", and other.
I think you're going a little too far here, though I could support that
reduction to a certain extent.
>Without information on the names of valid entities and notations,
>and potentially without information on IDs, then ID, IDREF,
>ENTITY and NOTATION are indistinguishable; IDREFS, ENTITIES, and
>NOTATIONS also all look the same. The only remaining distinction
How do people feel about this? Is getting a normalized list of entities from
an XML parser too hard? How about notations? Or should notations be brought
into the XSchema spec? (They have a section in the current outline.)
>Saying what the specific default value is or whether there is none
>is overspecific (the DTD must bear this information, and
>an XSchema would be either redundant or conflicting, a Bad Thing);
>the only three cases are: a) the value must be present and must
>be "foo" (#FIXED), b) the value must be present but can be anything
>(#REQUIRED), or c) the value need not be present.
Conflicts between DTDs and XSchemas are something we need to consider for
processing in general, not just with entities. (Which we seem to have
I have to admit that when I first started out on this path, I wanted to strip
XML down to its barest syntactical foundations - what I call simple XML - and
rebuild the DTD syntax, entities and all. The more I've looked at DTDs, with
help from many of the contributors on this list, the less I wanted to rebuild
the entire structure. DTDs do too damn many things, not all of them well.
(In this regard, they remind me very much of HTML, actually.)
The processing model I'd like to be able to use for XSchema revolves around
_well-formed_ documents, not the simple documents I was talking about earlier.
(For those interested in simple XML, there's a chapter on it in my next book,
and it more or less is similar to the tools covered in Chapter 3 of XML: A
Using the full possibilities of well-formed documents allows us to use general
entities without any difficulties, and means we don't have to create anything
weird that tells parsers not to touch the entities. In short, we can build on
the non-validating parsers already available, and create 'real' applications
The fun part comes in building a separate validator. I'd like to see a
validator (we need to come up with a different name for it) that can use the
SAX API to read in both the document and the XSchema. Applications that use
XSchema will need to avoid validating parsers, unless we can figure out a way
to allow DTD validation and XSchema validation/verification/whatever 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