Noah has given me some feedback on the schema-comments list that I would like to forward (with permission) and respond to. Noah_Mendelsohn/CAM/Lotus@l... wrote: > > The schemas WG has given very serious consideration to the view that > validity constraints should be somehow separated from anything in the > schema that affects content. Entities do affect content and could be > eliminated or perhaps "put in a box" as you suggest. [by put in a box he means to make a separate specification that would handle them] > The more difficult case, I think, is default values for attributes. These > too affect content (and in the case of default values for namespace > attributes can affect the deeper meaning of the document structure.) > Anyway, we've heard strong opinions expressed that (1) default values for > attributes are an important feature of any replacement for DTDs and (2) > that it would be very cumbersome to define the default values somewhere > that is far removed from the declaration of the attribute itself. The > natural place to introduce a default does seem to be on the attribute > declaration. I agree, this does seem natural. Here are reasons it seems natural: a) people view the DTD document as documentation for the language b) DTD writers want to communicate to application writers that there is some specific default that makes the most sense c) DTD writers want to be able to change their mind about the specific default later. What if we rethought the attribute default mechanism in terms of these goals? Instead of having default attributes change the parse tree as seen in a DOM 1.0 tool, (i.e. at the lowest infoset) we can have them attach extra nodes to the infoset that the application gets by viewing the data through the schema. The necessity of this infoset is a given: how else will applications know their data types and so forth? In other words, attribute defaulting is a service provided by the schema engine to the application just like data type recognition and attribute value type recognition. It would NOT be a service provided to or by the parser (using the old fashioned definition of parser that did not include the entire universe). Probably defaulting would occur after namespace application (which wouldn't need it) but before (e.g.) XSL application (which would). If it makes it clearer, we can even stop referring to it as a default value and instead refer to it as a "suggested value." And note that you can build this as a SAX filter or DOM layer on top of XML 1.0 SAX or DOM. Text entities cannot really be rethought this way because XML 1.0 requires them to be resolved before anything else can proceed. Plus text entities are probably just not a good idea anyhow: we should be glad to let them die out. > So, depending on how you feel about that analysis of attribute values, > pandora's box is then open. I can see that the box is open but only a crack. If we think of the levels as: 1. physical 2. logical 3. DTD/schema-augmented logical Then default attributes can be considered to be at level 3. If we want to push them back into the parser (I advise against it) then we could call them level 2. But to influence level 1 from level 3 seems particularly gruesome and not backwards compatible. If we do it the "wrong way" then attribute defaulting is analogous to an ingrown toe-nail but text entity insertion is more like an ingrown toe. (sorry!) > The schema can afffect the contents of a > standalone=no document. Having, with regrets, crossed that bridge, does > that change the net tradeoff on entities? Maybe. The standalone=no > document is already potentially dependent on the schema for other reasons, > I.e. attribute defaults. Now the question is: be a proper superset of > DTD, including questionable features, or leave out entities? > > Anyway, these are some of the issues we wrestled with. You can see where > we landed this time. Thanks again for the feedback. > > Noah -- Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco Diplomatic term: "Regret" Translation: To care, but not enough to condemn. ("We regret the loss of life in Sierra Leone. We have no intention to do anything to stop it, mind you, but we regret that it happened.") (Brills Content, Apr. 1999) 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