[
Lists Home |
Date Index |
Thread Index
]
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 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.
On "binary XML". If you read my earlier postings in the
list, you will see that I have consistently argued that
there should be NO "binary XML." We already have widely used
and effective binary encoding standards that are used to
enable everything from the cell phone system to our network
management services (SNMP) to our directory services (LDAP),
etc. We don't need a "new" binary encoding standard even
though there are a number of folk in the XML community who
seem to want to create one. Leave XML to textual-encodings.
ASN.1 has already dealt with the binary problem.
Our focus should be on working together, not on
recreating each other's work.
bob wyman
|
