OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] ASN.1 is an XML Schema Language (Fix those lists!) and Bin

[ Lists Home | Date Index | Thread Index ]

Michael Champion wrote:
>Can ASN.1 systems handle mixed content and open content models, e.g.
> 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
         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
         need to get compact encodings for speed of transmission or 
         economy of storage during production, you can switch to
         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
         existing encoding rules suits one or another specific purpose
         such as tight-encoding, fast encoding/decoding, textual
         etc. You get a suite of options to pick from in designing
      3. The ASN.1 Encoding Control Notation defined in X.692 allows
         to define custom encoding/decoding rules to address
         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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS