[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
> On one hand this proposal has "nothing to do with XML".
> On the other hand it requires extensions to key XML parsing
> technology. Can you please explain why this is good?
SAX2 explicitly provides for extensions which can be
implemented independently and do not require modification of the base
interface. Thus, I don't see the damage that is done by my proposal.
No existing standard needs to change. The question is: "If someone is
going to build such an extension, what is the best way to do it
without breaking compatibility with all the existing users of SAX?"
Perhaps this is not the right time or forum for this
discussion. Let's just consider this a preview of the debates that
will occur if efforts to define a new "binary XML" continue. In one
forum or another, we're going to have to work through these issues if
the textual-vs-binary permathread is ever to be killed off for good.
After running for more than 20 years, this debate really should come
to an end.
In any case, it is clear that a SAX interface to binary data
is only really useful if it is 100% SAX compliant. Whether it is
able to provide a superset of SAX (i.e. support for non-string types)
is secondary to whether SAX is properly supported. Also, it should be
clear that a SAX interface to the ASN.1 defined binary encodings, even
if only strings are supported, would be very useful to the binary
encoding world since it will allow them to leverage the massive number
of existing tools that already rely on SAX.
Two vendors, Objective Systems and OSS Nokalva, claim to be
working on SAX interfaces to ASN.1 defined encodings. Let's hope that
they both deliver fully-compatible SAX 2 support (including
character()) before moving on to do anything more exotic.
bob wyman
|
