[
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
>
ABS
|
