No subject

roddey at roddey at
Thu May 13 20:48:41 BST 1999

>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 at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list