[
Lists Home |
Date Index |
Thread Index
]
Michael Champion wrote:
>Can ASN.1 systems handle mixed content and open content models, e.g.
XHTML?
> I haven't heard anyone advocate it for more content-oriented,
> document-like uses.
One of the first applications of ASN.1, back in the early
80's, was to define the file format for a wordprocessor that was a
component of ALL-IN-1 (at the time, it was the market leading Office
Automation package.) That word processor had all the bells and
whistles that you find in HTML today. (i.e. bold, underline, font
changes, paragraphs, embedded tables (actually spreadsheets),
graphics, etc.) There is NO question that ASN.1 can be quite easily
used for this purpose. I've done it. It works. We had a business of
close to $2 billion per year largely based on it at Digital. (We also
used ASN.1 in our mail system.)
>If ASN.1 is an "XML" technology, isn't it a "binary XML" system,
>that is, an alternative Infoset with a range of possible
>serialization formats?
ASN.1 is an "Abstract Syntax Notation." Thus, it doesn't make
sense to refer to it as "binary XML." ASN.1 is no more "binary" than
it is "textual." XML on the other hand is a "concrete syntax." An
Abstract Syntax is independent of concrete encoding syntax or format.
What ASN.1 compilers do is build control tables that are then passed
to encoding modules that produce one or another encoding. Thus, I
compile the ASN.1 syntax and then call either an XML encoder/decoder
or perhaps a PER (Packed Encoding Rules) binary encoder/decoder to
convert my data structures into some concrete encoding.
> concrete advantages ASN.1 might offer in specific circumstances
> would help spread the word.
The key advantages of ASN.1 are:
1. Allows programs to be based on abstract syntax rather than
concrete syntax. This allows decisions on precise concrete
encodings to be deferred to the last minute. It also means
that
developers are able to chose encodings as a configuration or
optimization function. For instance, you can use XML (via XER
or XML Encoding Rules) during development when you want to
to be able to debug on-the-wire packets easily. Then, when
you
need to get compact encodings for speed of transmission or
economy of storage during production, you can switch to
something
like PER (Packed Encoding Rules).
2. A large number of encoding rules already exist for ASN.1
defined data (XER, CXER, EXER, BER, DER, PER, etc.). Each of
the
existing encoding rules suits one or another specific purpose
such as tight-encoding, fast encoding/decoding, textual
format,
etc. You get a suite of options to pick from in designing
your
application.
3. The ASN.1 Encoding Control Notation defined in X.692 allows
one
to define custom encoding/decoding rules to address
application
specific needs or legacy requirements like encoding data into
packed bitmaps, etc.
4. ASN.1 has been in development for over 20 years now...
bob wyman
|
