[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>SAX is XML parsing API.
No. SAX is just an interface -- it has nothing to do with XML.
It is a well established principle of computer science that one should
separate "interface" and "implementation." All SAX does is define an
interface that presents a stream of events. Sure, the interface was
defined with XML handling in mind and it is inevitable that any (if
any) modifications to it will primarily be driven by XML concerns,
however, that is largely irrelevant. SAX is a great interface for
working with XML. It is also a fine interface (even without
extensions) for working with ASN.1 defined binary types, CSV files,
etc. With a little extension, done in the time-honored tradition of
object oriented design and using standard Java language facilities, it
can be made better for dealing with typed cases...
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.
> Thus I think that functionality should appear in its
> own API, which may or may not look a lot like SAX.
Sure, I could create "SAD" and then copy all the SAX 2
documentation (Is there copyright problem here?) 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?" And, we'd have people say: "If SAD is just as good at
handling XML as SAX is but SAD can also handle binary formats, why
don’t I just use SAD and dump this SAX thing?" This would also mean
that people like Harold, St.Laurent, etc. might be able to write new
books on SAD... I can already imagine the XML Deviant article: "SAD vs
SAX: Which is right for you?" Give me a break.
> Plus if it's really that simple, why can't some of the
> ASN.1 folks build a SAD engine as proof of concept?
I did it last night. It works fine. (Oh... I should say that I
realized when doing it that I need to extend Attributes.getValue as
well...) No, you can't see my code. It's ugly, not ready for prime
time, and depends on a proprietary encoder/decoder.
bob wyman
|
