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

No Subject

  • From: roddey@u...
  • To: xml-dev@i...
  • Date: Thu, 13 May 1999 12:46:45 -0600

No Subject

>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...)


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.
First Name
Last Name
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.