[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> I'd be thrilled to see ASN.1 readers which produce SAX2 events and ASN.1
> writers which consume SAX2 events. I'm not happy to hear notions of
> PSVI-like typing polluting the SAX2 space. If you want typing, find
> another API - and accept the costs of doing that. If the ASN.1
> community wants to reach out to the XML community, it needs to create
> ASN.1 tools which talk to XML tools without imposing ASN.1's own and
> different perspective on how data should be presented.
I agree - don't jump to the conclusion that the ASN.1 community wants to
impose anything; in my experience of moving amongst them, they don't
want to impose anything on anybody apart from themselves, in pursuit of
the greatest quality of available XML tools for the users! :-)
The only part of SAX which is really "string specified" is that fact
that the leaf nodes and attribute values are represented by strings,
right? I mean, there's probably some parser properties that only really
have any meaning when dealing with strigs - perhaps one were you specify
the character set - but that's a minor issue; a non-textual SAX source
just ignores that option, I presume.
Now - to pass information to an application that involves typed values
but is otherwise structured like XML, we have two options.
1) Have an optional SAX extension that emits typed values instead of
character strings; of course, since we are neither stupid nor evil,
we'll make it totally optional, so valid SAX implementations are under
no burden to implement it if they don't want to, applications that don't
use it are unchanged by its presence, etc.
2) We make an entirely new API which is pretty much identical to SAX
exception that everything's renamed, and the leaf node / attribute value
callbacks use Object (or your language's equivelant) instead of char[].
The argument for (1) is that it seems like a bit of a reinvention of the
wheel, particularly since in many situations, an application would want
to treat a part of an XML document as typed structured information while
treating bits of it it's not interested in as characters to pass through
verbatim and not worry about attempting to interpret them as anything,
like my timeStamp example - meaning that the same application really
wants to work with both models in parallel.
Now, as I see it, the argument for (2) is that a backwards-compatible
optional extension to SAX might be a bit messy (having characters() and
value() callbacks, along with something to allow attributes values to be
provided as native data - even when some other attributes might not be
typable by the parser...), rather than any fear of it polluting XML,
since we clearly *can* do it in a non-polluting way...
ABS
|
