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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] SAX for Binary Encodings (SAD-SAX)

[ Lists Home | Date Index | Thread Index ]

Bill de hÓra wrote:

>>     What is it about this proposal that generates the heat?
>> Obviously, I'm missing something here. Please try to explain the issue
>> as clearly as you can. 
> SAX2 is designed to process XML. XML is encoded with Unicode. Your
> proposal is trying to work around that.

You say SAX2 is designed to process XML, but what in the API really 
forces that?

SAX2 is designed to process something that has leaf nodes of text (be 
they character data or comments or PIs) wrapped in nestable containers 
which have a textual name and a mapping of textual 'attribute' names to 
textual values, right?

XML is one such thing, but there are *already* others. SAX will work 
just fine with those, too.

You can have an entire SAX pipeline without a single byte of XML; a 
database backend that emits SAX events 'faking' an XML document that 
goes into an XSLT engine that outputs a string of HTML. No XML actually 
involved! There's a conceptual 'virtual' XML document that exists 
between the database and the XSLT engine, but no pointy brackets were 
harmed in its construction :-) I presume this is quite common; I've 
personally been involved in a project that did something similar, just 
with DOM trees instead of SAX as the glue.

All the guy is proposing to expand upon is the idea that element and 
attribute content be optionally presented by the SAX API as native 
values, where the SAX parser has enough information to do so. He didn't 
explicitly state that there would be mechanisms to handle the case where 
type information is still available, perhaps because he incorrectly 
assumed that the readership of his email would stop and think "Oh wait, 
SAX *already* works where there's no type information available! So it 
can just fall back to that behaviour or something! Not a problem!", so 
didn't sit and explain the obvious at them? :-)

>> And, as Amelia demands, it
>> is not defined "in terms of WXS" or any other type system. This is
>> good since SAX shouldn't be encumbered with the debate over these type
>> systems. Let those battles happen elsewhere.

> I think the issue is that some are wondering why SAX ought to be
> encumbered with non-Unicode forms for Infosets.

It doesn't have to be non-Unicode, now, does it? It would be quite 
useful for normal XML with an associated schema, too. The original 
poster was coming at this issue from the viewpoint of binary encodings 
where it's more efficient to present the code directly with a native 
integer than to convert from two's complement form to text only to have 
the application convert back again - but the application of a 
typed-values-in-SAX interface is wide than that!

> Bill de hÓra



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

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