OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   No Subject

[ Lists Home | Date Index | Thread Index ]
  • From: roddey@us.ibm.com
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 13 May 1999 12:46:45 -0600





>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@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS