[
Lists Home |
Date Index |
Thread Index
]
Stephen D. Williams wrote:
> ASN.1 is based on certain assumptions that are not
> true of every situation that needs better efficiency
> than XML 1.1. As an example shoehorning self-description
> into a format that was explicitly designed in the
> opposite way doesn't seem like the best path, to me.
Clearly, you do not understand ASN.1 very well. First, ASN.1
is just a schema language -- it is not an encoding format. But, it is
a schema language that was first used to define self-describing binary
data streams. These were encoded using the (Basic Encoding Rules)
which relied on "tag-length-value" encoding. (i.e. each value is
tagged with its type and its length). You can think of BER as ASN.1's
own "XML". i.e it is very easy to read (assuming you're comfortable
with binary and have a schema to look up the non-standard type
numbers), very easy to write, and it is bulky (because of all the tags
and lengths). Note: There is even the equivelant of "namespaces" in
ASN.1... These are driven off an ISO maintained OID (object
identifier) tree. Thus, you can ensure that your tags are globally
unique. (Admittedly, many will argue that the OID method is
unnecessarily cumbersome...)
Other encoding rules for ASN.1 have been defined. For example,
there is XER (XML Encoding Rules -- basically BER with text tags...),
CER (Canonical Encoding Rules) and DER which are useful when doing
signed stuff, and PER (Packed Encoding Rules) which are highly
efficient and compact. If you only look at PER, you might get the idea
that ASN.1 codings aren't self-describing. That's because PER is the
"schema-based" version of ASN.1 while BER is sort of like the
"schema-free" version of ASN.1 encodings.
Note: The ASN.1 community went through much the same
progression that some people hope the "XML" community will go through.
i.e. BER was self-describing and could actually be parsed without
schema knowledge. But, it was inefficient and fat (but smaller than
XML in most cases). PER was able to get compactness and efficiency by
forcing the parser to understand the schema. You choose which to use
based on your need.
The schema-free vs schema-required arguments raged many years
ago in the ASN.1 community. What it basically comes down to is that
which is right depends on the application. If you've got a great deal
of variety in what you're receiving and the format definition
frequently changes, then use something like BER. But, if you've
stablized your format and it doesn't change more frequently than
you're able to deploy a new schema, then PER is great.
In summary: There is no need to "shoe-horn" self-description
into ASN.1. It has been there since day one. i.e. almost 20 years
now...
bob wyman
|
