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] Re: ASN.1 is an XML Schema Language (Encoding Control

[ Lists Home | Date Index | Thread Index ]
  • To: "'Pete Kirkham'" <pete.kirkham@baesystems.com>, <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Re: ASN.1 is an XML Schema Language (Encoding Control
  • From: "Bob Wyman" <bob@wyman.us>
  • Date: Thu, 6 Nov 2003 12:39:54 -0500
  • Importance: Normal
  • In-reply-to: <"031106132353Z.WT12372. 8*/PN=Pete.Kirkham/OU=Technical/OU=NOTES/O=BAe MAA/PRMD=BAE/ADMD=GOLD 400/C=GB/"@MHS>
  • Reply-to: <bob@wyman.us>

Pete Kirkham wrote:
> If the encoding was expressed in suitable form, then that 
> could be retrieved and compiled instead having a library 
> of native decoders.

If you use the ASN.1 Encoding Control Notation, you could can then
define your abstract syntax in ASN.1 and define your encoder/decoder
in Encoding Control Notation. The result is that you get XML, BER,
PER, etc. for free and you can use the ECN to generate
encoder/decoders for your special format. The really wonderful thing
about this is that your specification is "executable" and generates
encoder/decoders deterministically and automatically. The result is
that you don't have to suffer the normal delay between writing the
specification seeing the first implementations. The specification
itself *is* the first implementation! This massively decreases the
effort needed to support the new encoding and ensures that you have a
reference implementation immediately.

> Since one of the projects I work on has to support legacy text
> random formats from other tools, its own XMI data and SOAP messages 
> (which are essentially aliases of each other), I can think of one 
> use case for plugging encodings like this; but at the moment someone

> ends up writing the encoder manually, rather it being generated off 
> a concrete syntax description.
	If you were using ECN, then the process of coming to
"understand" the legacy format would be one of writing the ECN
definition for the encoding. To actually generate the
encoder/decoders, you would just compile the results of your research
on the legacy format. Thus, you wouldn't have people doing manual
construction of encoders any more and you would "debug" your
encoder/decoders by fixing the ECN specification, not the actual
source code...
	Also, assuming that part of this process was defining the
abstract syntax for the legacy format, it means that once you were
done, transformations to alternate encodings like BER, XML, PER, etc.
would be largely labor free.

		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