[
Lists Home |
Date Index |
Thread Index
]
Alaric B Snell wrote:
>
> This is a strong argument FOR making this as an extension to
> SAX rather
> than a new API - if you had to switch to a totally new API for all of
> your XML reading to parse XPaths, changing bits of your code
> that really
> needn't change, that would suck!
>
Alaric,
I am still totally unconvinced that a "typed SAX" would be a good idea.
I don't really see the benefit for applications, if they receive
"pre-converted" data from the type-aware parser rather than performing a
conversion themselves on the character data they receive from the parser. I
do see a big benefit in letting each application choose how it wants to
represent that data in memory.
ASN.1 can work well with present, character-based SAX2. ASN.1-based
applications do not need a "typed SAX" any more than current XML
applications need it. And the benefits of having a universal parser API
which works equally well on every kind of XML document outweigh the
purported convenience of "pre-conversion" done by the parser.
I see the idea of a "typed SAX" as an attempt to introduce a form of
partial, shallow data binding into SAX parsing. Unlike in true data
binding, here the parser would not be producing a complete "unmarshalled
value" for the entire instance, but would be attaching a million little
"unmarshalled values" to the leaves of a SAX event tree and to the
attributes.
Why do we need this? Data binding is a very useful technique, as is generic
"typeless" parsing. ASN.1 applications have been using data binding for
decades. Now we need SAX for facilitating the coexistence of ASN.1
technologies and XML technologies and for enabling people to use them
together. But we need SAX2, not a mix of SAX parsing and partial data
binding.
Alessandro
|
