[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: Mon, 10 Nov 2003 10:01:00 +0000
• Cc: xml-dev@l...
• In-reply-to: <001a01c3a700$20516670$650aa8c0@BOBDEV>
• References: <001a01c3a700$20516670$650aa8c0@BOBDEV>
• User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

Bob Wyman wrote:

> 	No. SAX is just an interface -- it has nothing to do with XML.

As long as you hold that opinion, I can't see us getting anywhere.


> 	The utility of distinguishing interface and implementation has
> been often demonstrated in the examples of SAX readers/writers for
> non-XML encodings like CSV files (see David Brownell's SAX2 book) or
> GEDCOM (see Michael Kay's XSLT book). Given that DOM and SAX are
> usually considered interchangeable methods of addressing the same
> problem, I can also point to Michael C. Rawlins book "Using XML with
> Legacy Business Applications" which discusses conversions of CSV,
> flatfiles, X12 EDI, and other encodings to and from DOM.

None of those involved extensions to SAX. You don't seem prepared to 
acknowledge that. Your proposal involves extensions to SAX.


> 	Sure, I could create "SAD" and then copy all the SAX 2
> documentation (Is there copyright problem here?) 

No there isn't. As far as I know, being in the public domain, you 
have carte blanche to do what you want with it.


> and just add to it my
> tiny extensions. I would then have an interface that handled XML just
> as well as SAX does as well as handling ASN.1 defined binary
> encodings. But, everyone who read my documentation would be saying:
> "SAD sure looks like SAX to me! Why didn't this idiot just extend the
> SAX interface instead of making me dig through all this
> documentation?" 

Because that person did the right thing? Anyway this is a bogus line 
of thought.


> Give me a break.

No I won't :) I think Unicode processing will layer on top of such 
an API much better than the other way around. Nothing you've said 
here has convinced me otherwise, definitely not an argument along 
the line of; SAX has nothing to with XML, ergo it's fine to alter it 
for binary streams and datatype binding. In fact SAX is optimized 
for XML processing, right down to the acronym;  if that wasn't the 
case you wouldn't need alterations to suit your purpose.

Bill de hÓra
-- 
Technical Architect
Propylon
http://www.propylon.com

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

• Prev by Date: RE: Reusing, Refactoring, Reinventing??? (was Re: SAX for Binary Encodings (SAD-SAX)
• Next by Date: Re: SAX for Binary Encodings (preserving investment) (ASN.1 and SAX)
• Previous by thread: RE: SAX for Binary Encodings (SAD-SAX)
• Next by thread: Production 78 in XML 1.1
• Index(es):
  • Date
  • Thread