xml-dev - RE: Argh...Entities

[Ronald Bourret <rbourret@ito.tu-darmstadt.de>]

Tim Bray wrote:

> At 02:27 PM 5/11/99 -0400, John Cowan wrote:
> >Your argument is sound.  I am converted.
> >Down with all entity declarations in XSchema!
>
> I'm starting to feel that way too... (BTW, I am *not* on the
> Schema WG); but there is an awkwardness in that it would be
> nice if schemas were a pure superset of DTDs.  Which they
> can't be if they don't do entities.

I agree with Paul that the major reason for not defining entities in a 
schema language is to separate per-document resources (entity definitions) 
from per-document-class resources (element, attribute, and notation 
definitions).  This was the conclusion I reached that converted me.

I would also like to point out a couple of other things.  First, the 
validity constraint that checks if an entity attribute contains a valid 
unparsed entity name is really no different from the validity constraint 
that checks if a general entity reference contains a valid general entity 
name.  That is, the following are analogous -- both are entity references 
-- in spite of the fact that the actual syntax is different:

   <!-- bar is an ENTITY attribute; foobar is an unparsed entity -->
   <foo bar="foobar"/>

   <!-- barfoo is a parsed general entity -->
   <foo>&barfoo;</foo>

If it is OK for the physical processor to check that the second is valid, 
it is also OK for the physical processor to check that the first is valid. 
 That the first can be checked post-parse is a red herring.

Second, separating physical and logical definitions necessarily implies 
splitting validity into physical validity (Entity Declared, Standalone 
Document Declaration, etc.) and logical validity (Element Valid, Required 
Attribute, etc.).  Physical validity is the responsibility of the parser 
and logical validity is the responsibility of the schema-processing module 
(which may be part of the parser).

In response to Tim's point that it would be nice for schemas to be a pure 
superset of DTDs, why not have separate physical and logical schema 
languages?  The physical language could be used on a per-document basis and 
the logical language on a per-document-class basis.

The only reason I could think of for schemas being a superset of DTDs -- 
other than familiarity -- was converting DTDs to schemas on the fly for 
backwards compatibility of schema-driven software to documents with DTDs. 
 However, this reason doesn't hold water.  My experiments with converting 
DTDs to DDML showed me that I would have to build an intermediate object 
model -- streaming was not possible -- so there is no reason I couldn't 
build separate models for physical and logical definitions.

(By the way, who needs entity definitions in instance syntax, anyway?  The 
only example I have seen is the document fragment specification.  Granted, 
this is a very convincing customer, but a separate physical schema language 
would satisfy their needs.  Are there others?)

-- Ron Bourret


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/ and on CD-ROM/ISBN 981-02-3594-1
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)