[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ASN.1 and XML
- From: "Al B. Snell" <alaric@alaric-snell.com>
- To: The Deviants <xml-dev@lists.xml.org>
- Date: Thu, 24 May 2001 17:22:43 +0100 (BST)
On 24 May 2001, Simon St.Laurent wrote:
> You've been making claims that ASN.1 is competition for XML. I'd like
> to see some backing for those claims.
The only edge XML has over ASN.1 encodings is that XML has hype, and
therefore lots of available toolkits... well, the ASN.1 type notation is a
bit gnarly to parse right now, but those parsers are not needed in
programs that use ASN.1 encodings; just in the codec generators in the
toolkits used at compile time, and there is some interest in defining a
notation for ASN.1 types in ASN.1 itself, much like XML Schema replacing
DTDs. I think this would be neat.
Point to something you can do in XML that you can't do in ASN.1 :-) XML is
only competition for ASN.1 because it's being pushed by hype; there's
nothing it can usefully do that couldn't be done as well or better before.
One big win of ASN.1 over XML is that, from the same "schema", you can use
different encoding rules. When debugging/testing, or other situations
where you want to be able to see what's going on and you don't have a nice
BER disassembler, you can use a textual encoding (we're working on one
that even uses angle brackets and is well formed XML!); for general use
over a network, BER contains enough type information to be disassembled
into a meaningful tree structure of atomic types and compound types; or
for embedded/wireless domains and their kin, you can use PER which
produces a very simple, compact, encoding. The selection of what your
encoder outputs is just a compile-time choice of which encoder modules to
compile up then a run-time configuration option. Likewise, the decoder can
support any set of decoding modules, and accept all of them.
BER is like XML without the element/attribute names, just numbers in
place. PER is like XML without any identifiers, but usage of the schema to
know what's expected in what order, and a small number field of a few bits
where there's a choice.
Another win of ASN.1 over XML is 15 years of practical experience using it
in the real world. That's hard to beat :-)
ASN.1 is easy to learn... there are books out there that cover it all
quite nicely. And you don't even need to read all of them.
There is a shortage of open source toolkits that fully support the
functionality, but the encoding rules can be read by hand to generate
encoders/decoders, as is often done for common ASN.1 based Internet
protocols (SNMP, LDAP, etc). However, if the effort being put into XML
parsers was put into an open source ASN.1 toolkit for C, C++, Java, Perl,
and Python, then we'd have a tool that does more than XML currently does,
and XSLT and friends could be built on top of that without reinventing
wheels. This is what annoys me about XML. We're reinventing the wheel, and
not even doing it as well, and nobody listens; they think they've come up
with something amazing and new when the only advantage XML has over what
has gone before is that due to timing and luck it's got into the minds of
the marketroids.
However, there is still hope; we're working on techniques for
interoprating ASN.1 with XML, so it will be possible to implement "XML
systems" that actually use superior ASN.1 encodings and abstract syntax
(=schema) internally, yet still interoperates with the heathens by just
seeing XML as another encoding. I'm personally going to try to suggest in
the right places that a better open source ASN.1 toolkit be
developed. Maybe the good people as OSS Nokalva might find that releasing
their ASN.1 toolkits into the open source world increases the demand for
ASN-1 step (http://www.oss.com/products/asn1step.html) and their courses.
ASN.1 supports unexpected extensions of the protocols by third parties.
Even ONC XDR has version support, dammit. XML IS NOT THE FIRST "NON RIGID
FORMAT" NOTATION! Any decent format allows unexpected stuff to turn up,
and a few even let the unexpected content carry flags explaining if it can
be ignored or not. (such as the chunk format used by PNG or MNG, inherited
from the Interchange File Format: read
http://www.borg.com/~jglatt/tech/aboutiff.htm - 'By establishing
Interchange Format Files (ie, IFF) and releasing the documentation for
such, as well as C source code for reading and writing IFF type of files,
Electronic Arts has helped make it easier for programmers to develop
"backward compatible" and "extensible" file formats' - in 1985. So this is
the amazing new thing XML brings us that will change the world, yes? :-)
XML is not the first notation to support the idea of schemas and
namespaces allowing you to embed things from different schemas in your
schema. XDR has primitive support using opaque strings, ASN.1 has support
at the same level as XML by using a concept like a namespace, the OID.
Here is some ASN.1 in a human-readable encoding, the value encoding used
to specify constants in an ASN.1 type declaration:
http://www.warhead.co.uk/oid/al-mobile.asn1
In XML Value Notation, that'd be:
<MobilePhone xmlns='urn:oid:1.2.826.1.4062548.2.1.0'>
<number>447974437842</number>
<handset>Nokia nk702</handset>
</MobilePhone>
It's my mobile phone. It refers to a type defined in:
http://www.warhead.co.uk/oid/contact.asn1
The things in round brackets:
{ iso(1) member-body(2) uk(826) ltd(1) warhead(4062548) publications(1) contact(0) }
...are object identifiers, and work like namespace URIs. In fact, they can
be used as URIs:
urn:oid:1.2.826.1.4062548.2.1.0
...is a shorter but less readable form of the above OID.
Seeing intelligent people getting all excited over XML makes me worry. Am
I and the sympathisers I communicate with really mad to find XML somewhat
disappointing compared to existing technologies that do the same
thing? What is the world coming to? Why do I bother? I devote my life to
the study of fundamental platform/tool technologies, exploring the state
of the art, and people go and use *XML*...
I really have never seen anything you can do with XML that you can't do
better in ASN.1, apart from the tools-available issue, which is silly!
:'-(
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