[
Lists Home |
Date Index |
Thread Index
]
Bob Wyman wrote:
> Give me a break!... this is *not* a good thing to use to prove incompatibility
> between XML and ASN.1.
Of course not. I was just pointing out that the reference probably
wouldn't cut much ice with the people you addressed it to.
> What is the proper forum in which to hash out the details of
> such a type-rich interface for a "SAX 3"? Is it this group (xml-dev)?
> Or somewhere else? Given that we can see that there are already two
> commercial vendors working on SAX interfaces for the ASN.1 defined
> types, and given that a such an interface will be needed/required by
> *any* SAX interface to binary encodings, it probably makes sense for
> us to define the interface we want as soon as possible so that we
> don't end up stuck with the inevitable confusion that comes from
> competing solutions.
I see that others, who are in a better position to know than I, have
advised you that there is no such forum within W3. Maybe they're right.
However, if I wanted to push this agenda, I'd try to hook up with the
"binary XML" effort.
To clarify my previous suggestions, as open source projects:
1. Implement the full SAX 2 API over a meaningful subset of ASN.1.
Maybe it's just me, but you can say 'till you're blue in the face that
the full SAX 2 API can be supported over ASN.1. When I see the code,
I'll believe it.
2. *Then* prototype an extended SAX API compatible with the above that
has just enough change to allow it to serve up internal datatypes on
demand. The more type system agnostic (while still meeting the desired
performance goals) this can be, the better.
I don't see this hypothetical prototype so much an "incompatible
solution" as a talking point. Some in the community have well-developed
antibodies against solutions in this space. Working code has served as
the voice of sweet reason in the past; it might do so again.
Bob Foster
|
