[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX for Binary Encodings (SAD-SAX)

• Subject: Re: SAX for Binary Encodings (SAD-SAX)
• From: Bill de hÓra <bill.dehora@p...>
• Date: Sat, 08 Nov 2003 22:10:26 +0000
• Cc: xml-dev@l...
• In-reply-to: <001401c3a62b$7466e210$650aa8c0@BOBDEV>
• References: <001401c3a62b$7466e210$650aa8c0@BOBDEV>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

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

• References:
  • RE: SAX for Binary Encodings (SAD-SAX)
    • From: "Bob Wyman" <bob@w...>

• Prev by Date: RE: SAX for Binary Encodings (SAD-SAX)
• Next by Date: Re: SAX for Binary Encodings (preserving investment) (ASN.1and SAX)
• Previous by thread: RE: SAX for Binary Encodings (SAD-SAX)
• Next by thread: RE: SAX for Binary Encodings (SAD-SAX)
• Index(es):
  • Date
  • Thread