[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> make changes to XML processing ....
> That's what Bob seems to be up to
This is a complete misrepresentation of what I'm "up to". My
apologies if my intentions have not been clear, unlike you, I am not a
professional writer... However, I am *not* suggesting any changes to
XML processing. I have only spoken of processing non-XML encodings in
a manner which is similar to that used to process XML.
One of the problems with support for ASN.1 defined encodings
is that there is no standard API for dealing with the stuff. All the
existing standards focus on the encodings or the ASN.1 language. The
same is true for most other binary encodings. The result is that if
you buy one vendor's product or use one of the open source solutions,
you're stuck with that decision unless you want to rewrite all your
code. Also, most of the interfaces I've ever seen for binary encodings
have been either DOM-like or have relied on what can be described as
object serialization. There aren't a lot of event-based parsers like
SAX.
Now, given that it is very useful to represent binary
encodings as SAX event streams and given that this means that coders
will need to learn SAX, etc., and given that SAX presents 90% of the
interface for a great event-driven parser for binary-encodings, it
would be nice to see a superset of SAX become a commonly accepted,
standard interface for dealing with ASN.1 (not XML) encodings. The
alternative would be to take the SAX spec and just randomly change all
the class names, mix the order of parameters, etc. just to say that
"it isn't SAX it is SAD". (Then we can have SAD vs SAX battles for the
next 20 years...) But, that feels very, very silly. Why should an
attempt to leverage the experience gained in defining SAX -- without
changing the way SAX works for its current users, cause so much fury?
Reuse and learning from experience are supposed to be good things...
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.
Well, some vendors claim they are building precisely that.
Let's hope they do it right.
Clearly, starting this discussion of leveraging SAX was a
mistake. Clearly the emotions are too high and there is too much
suspicion of hidden agendas in the air.
bob wyman
|
