[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Argh...Entities
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@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|