Lists Home |
Date Index |
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
Because that person did the right thing? Anyway this is a bogus line
> 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