[
Lists Home |
Date Index |
Thread Index
]
At 11:36 AM -0500 11/9/03, Bob Wyman wrote:
> How is writing a SAX interface to ASN.1 defined binary
>encodings any different from writing a SAX interface to CSV
>files? Or, to GEDCOM (the genealogy data format)? I've seen
>both of these as examples in books written by respected XML
>authorities. Neither of these formats is "XML", yet, those
>authors are not condemned for showing or teaching people how
>to use SAX on non-XML data... The ability to strap non-XML
>data into SAX is, in books that teach people how to use SAX,
>often presented as a great *strength* of the interface.
As long as you don't try to change SAX to make it work better with
GEDCOM or CSV I'm fine with that. The issue is that you're trying to
make SAX more bloated and complex to better support your non-XML
format. This is what I object to.
> As others have pointed out. SAX2, as it stands today,
>is a perfectly good interface for working with ASN.1 defined
>encodings. It *needs* no changes. This isn't just my
>personal opinion, it is backed up by statements in this list
>from someone working for a vendor that is building a SAX2
>interface for ASN.1 defined encodings. My proposal only
>suggested an optional *extension* to SAX (using the normal
>SAX extension mechanisms) that would make working with SAX
>just a little more comfortable for someone who is used to
>working with typed data. I fail to see the harm in that.
Then you haven't spent a lot of time trying to teach and explain this
stuff. There's a real cost to added features, especially optional
ones.
--
Elliotte Rusty Harold
elharo@metalab.unc.edu
Effective XML (Addison-Wesley, 2003)
http://www.cafeconleche.org/books/effectivexml
http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA
|
