RE: ASN.1 and XML

["Al B. Snell" <alaric@alaric-snell.com>]

On Thu, 24 May 2001, Frank Richards wrote:

> XML (and SGML before it) lets people and machines interoperate...You're
> claiming that you have a better solution for machine/machine interaction.
> You may well. But XML is aimed at the large class of systems with people in
> the loop.

Ah! That class is large, but mainly boils down to:

1) Configuration files
2) Document markup (DocBook)
3) Programming languages (including things like XSLT)

In situations like RPC (or "Object Access", if you like SOAP :-), humans
do get involved, but only when debugging or reverse engineering. Not in
normal operation. A human-fiddlable form is useful in those development
cases, but should be an option for those cases rather than mandatory.

ASN.1 has existing tools to probe and edit the binary representations from
a GUI, and a value representation nearing standardisation (I think - the
ISO/ITU-T processes are still hazy for me) that coincidentally happens to
produce well-formed XML documents, so you can even use XMLSpy on them!

> And if it is much better for people/machine systems and only a little worse
> for machine/machine systems, then yeah, it will fill both niches in
> preference to maintaining two skill sets and infrastructures.

But ASN.1 isn't as disadvantaged for "real people" to deal with as many
seem to claim.

Here is an ASN.1 module, a set of type declarations equivelant to an XML
Schema:

http://www.warhead.co.uk/oid/contact.asn1

To pick a bit out of it:

MobilePhone ::= SEQUENCE {
        number  NumericString,
        handset UTF8String
}

The equivelant XML schema would be something like:

<xsd:element name="MobilePhone" type="MobilePhoneType"/>

<xsd:complexType name="PurchaseOrderType">
 <xsd:sequence>
  <xsd:element name="number" type="NumericString"/>
  <xsd:element name="handset" type="xsd:string"/>
 </xsd:sequence>
</xsd:complexType>

<xsd:simpleType name="NumericString">
 <xsd:restriction base="xsd:string">
  <xsd:pattern value="[0-9]*"/> <!-- I bet there's a better way of saying
		this, I'm not incredibly familiar with XSD myself :-) -->
 </xsd:restriction>
</xsd:simpleType>

...the information content and stuff is pretty identical; it shouldn't be
any harder for a developer to handle the ASN.1 than the XSD, seeing as
there are nice editors for both.

And as for the resulting values? With XER, both will produce something
like:

<MobilePhone>
 <number>...</number>
 <handset>...</handset>
</MobilePhone>

...yet the same ASN.1 can also produce (with PER) an encoding that uses
four bits per character in the phone number and the usual UTF-8 encoding
size for the handset name, and a small variable length length field for
each; this encoding will not need an XML parser to decode, a few lines of
C can do it (and be auto-generated from the ASN.1 type definition), and
run in an embedded environment. The magic that does this can be examined
by the user if they wish to learn, but is generally handled automatically
by the ASN.1 compiler. When developing this embedded system, the developer
can use existing ASN.1 protocol analyser tools to view and edit the dinky
PER encoding, or they might be using a simulator of the embedded system
that uses XER as the encoding to make the workings transparent, or they
might press a button on their ASN.1 compiler to make it generate a
converter from PER to XER and back for testing if they don't have a
protocol analyser package.

ASN.1 is absorbing XML as another value encoding; meaning that even if you
demand pointy brackets around named elements, ASN.1 will be able to do
that, but it will also be able to go into embedded systems or wireless
stuff where XML cannot tread.

This is a good thing.

Don't fear it...

> 
> Frank
> 
> PS. Don't forget printing the stuff and stuffing it in a vault...I bet there
> will be scholars who can read [pick a major language] long after the last
> tape or CDROM reader stops working.

Indeed, XER will be handy for that, or even a more verbose format that
includes type information and documentation (such as a copy of the ASN.1
type definition, complete with comments, bundled alongside an XER
representation of the data).

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software