Lists Home |
Date Index |
- From: Ronald Bourret <email@example.com>
- To: XML Dev <firstname.lastname@example.org>
- Date: Wed, 12 May 1999 11:26:48 +0200
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 -->
<!-- barfoo is a parsed general entity -->
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)