>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). > Hmmmm. Maybe I'm not fully understand you. But, if I am, this would be a serious problem with respect to performance. The parser really has to understand namespaces or you can never validate a stream based API, right? If the understanding of namespaces requires that it all happen after the fact, i.e. after its gone out the parser, then streaming protocols could not really be validated since the data would have to be accumulated until some part of the tree is built and can be validated, right? That would be kind of at odds to what makes streaming protocols useful. Or did I just totally miss the point? You *could* build it on top of SAX, but it would mean a very significant difference in performance. We can currently validate event output with a very small amount of overhead beyond the basic parsing overhead, because we understand such issues inside the parser and can apply the validation as the stream 'goes by'. If we had to give that up, though it would have other nice side effects, would be something to think hard about. Anything that makes XML perform noticebly worse is something to consider in its job as interchange language, right? 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