Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SAX for Binary Encodings (SAD-SAX)
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
