[
Lists Home |
Date Index |
Thread Index
]
Bob Wyman wrote:
> 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.
The ASN.1 use case imo needs an abstraction over an Infoset stream
and SAX is not quite that abstraction, not without changing it. XML
is predicated on Unicode and SAX takes the Unicode assumption
onboard. Not without retrofitting a callback for byte[] arrays (imo
might be a better option to callbacks with Objects and subsequent
downcasts) will you really get what you need.
Again I'll ask. Can you explain why altering SAX to work with
non-Unicode streams is a good idea?
> 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?"
My honest answer for non-Unicode streams at the moment is a separate
event parsing API. More below.
> 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.
Binary XML is a meaningless moniker unless you're equating Unicode
with Binary.
Various "text bigots" on this list have been through this before
with namespaces, infosets, rpc-encoding, datatypes, knowledge
representations - to the man these were meant to be simple and to
the man they turned out not to be so. Now it's the turn of
binfosets.What's interesting about all these past efforts is that
they came to the XML-enhanced web looking for something better. The
XML-enhanced web has not gone to type theory, abstract syntax,
abstract transports, object middleware looking for something better.
Nobody came from the Web looking for Middleware Services.
There is an onus to demonstrate why mucking about with a key
XML/Unicode processing API is a better idea than creating a separate
one for XML/Binary processing beyond asserting it's simple.
I'm skeptical enhancing SAX is the best approach. My gut feeling is
that it would be easier all round to start with a new SAX-like API
for binary encodings and retrofit Unicode streaming onto it.
Bill de hÓra
|
