Lists Home |
Date Index |
Amelia A. Lewis wrote:
> On Mon, 3 Nov 2003 16:02:29 -0500
> "Bob Wyman" <firstname.lastname@example.org> wrote:
> > this debate began and there is still no end in sight. But,
> the basic
> > principles of good design haven't changed. It is *still* better to
> > design using abstract concepts, not concrete and there is *still* a
> > need for non-textual encodings...
> "We reject kings, presidents, and voting. We believe in
> rough consensus and running code."
> -- Dave Clark, IETF, 1992
> The lesson of OSI versus TCP/IP isn't that "clean abstract
> design" (if such is possible, which I much doubt) beats
> running code. It's that the only way to get an acceptable
> design that runs in the real world is to take it back to
> committee after the implementers have had a chance at it.
> My bias: I've had to implement this stuff (because no one I
> ever worked for was willing to pay for tool kits, which were
> always either gloriously expensive or not available for the
> target platforms). From that standpoint (this was at a time
> when BER was what there was; DER was known but not used in
> the protocols of interest) it's horrible stuff, nearly
> impossible to eyeball except via hex dump and byte-by-byte
> tracking. TCP/IP protocols that used NVT were always easy to
> code for, easy to debug. SNMP and LDAP encoders/decoders
> were nearly as much of a pain as the Sun RPC stuff (which
> also used an abstract notation, XDR in that case).
> We believe in unicode and concrete syntax.
Good. So you don't believe in schemas. That's fine. Just use XML 1.0.
ASN.1 is not an option for you, as other schema languages aren't either.
ASN.1 *is* an option whenever a schema is considered useful or necessary.
In this case, you can just select XML 1.0 as the serialization format and
you will never have to cope with BER and PER.
On the other hand, you are certainly aware that there have been requirements
expressed for an alternative representation of XML 1.0 that is either faster
to parse or more compact (or both). ASN.1 meets most of those requirements,
as it provides PER and BER besides XML 1.0. It is just a matter of
selecting the appropriate encoding rules. Of course, if your applications
don't have any requirement for the extra speed and compactness, you don't
need PER and BER, but then you don't need any other possible binary
serializations of XML either.
This is the main difference between ASN.1 and other schema languages. While
other schema languages assume that XML 1.0 is the only syntax available,
ASN.1 is syntax-agnostic. The same ASN.1-based applications that produced
BER 15 years ago were able to produce PER 5 years ago and are able to
produce XML 1.0 today. Those applications will be able to produce a
different syntax in 5 years, as other encoding rules are standardized.
> Well, some of us do, at any rate.