[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Argh...Entities

  • From: Ronald Bourret <rbourret@i...>
  • To: XML Dev <xml-dev@i...>
  • Date: Wed, 12 May 1999 11:26:48 +0200

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.