Lists Home |
Date Index |
Rick Marshall wrote:
> i know conventional wisdom says convert to
> binary for efficiency.
But, as you point out, and as is clear to anyone who has any
real experience with binary encodings, they aren't always smaller,
faster, etc. There is no real debate on this subject (except from the
na´ve folk who haven't got much experience with binary encodings.)
However, *sometimes*, in *some* important applications, binary
encodings can be either smaller or fatter or faster or slower or a
combination of these. Even though we can all give lots of examples
where binary encodings are more trouble then they are worth, the fact
that they are sometimes well worth the effort is why the things still
One common misconception that has come up a few times in this
discussion, and I might have contributed to this through sloppy
writing, is that a Typed interface to SAX would *always* be faster
than the standard characters interface. This isn't true. In fact, even
when dealing with ASN.1 defined binary encodings, the need to convert
binary encodings due to endian issues or changing the representation
of floats, etc. can be just as expensive, for all practicle purposes,
as doing binary to characters conversions.
Binary encodings, typed encodings, etc. don't get you either
compactness or speed automatically. As always in this business, "It
> if it's so important to transmit data in asn.1
> why not have the xml set up properly. eg
> <fingers type="integer">10</fingers>
ASN.1 already defines mapping to and from XML as well as all
the binary encodings. An ASN.1 based system doesn't care if data is
encoded as XML or in binary formats. We don't need any new solutions
here. And, you don't need to put the "type='integer'" into your XML to
work with ASN.1 since a decent ASN.1 system that implements X.694 can
get that information from the schema.
> then write an xml to asn.1 transform in sax or xslt
> that produces something that can be easily compiled.
This can already be done if you have a SAX driver hooked to
your ASN.1 encoders/decoders. But, the issue isn't converting from XML
to ASN.1 defined binary encoding. The issue is: "How do you define a
common event based parser for both?" i.e. its an interface issue, not
an encoding issue.