Entities in XSchema - moving toward a processing model

[Simon St.Laurent]

John Cowan wrote:
>Many, many XML-DEVers wrote, in effect:
>
>> Entities in XSchemas suck big ones.
>
>I surrender.

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
>is syntactic.

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 
resolved.)

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 
Primer.)

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 
with XSchema.

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 
co-exist.

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)