Subject: Re: [saag] Why not XML? Was: WOES Bar BOF

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 30 Mar 2011 02:38:44 +0200

The main question that came up in the justification for the WG was whether
we could not do the same thing in XML or ASN.1. Here is an attempt at a
rationale:

The most important letter in XML is the X. It stands for eXtensible and a
mechanism that is designed to encode structured data in an extensible format
is necessarily more complex than one that is only designed to support
encoding of a list of tag-value pairs. Thus XML and ASN.1 are necessarily
more complex than the mechanisms discussed at the BOF.

XML and ASN.1 are necessarily more complex than a list of tag-value pairs,
but most of the objections come from the fact that they are also more
complex in ways that are unnecessary.

The mapping from a C# data structure to a XML or a ASN.1 reification can be
effected by a purely automated means. But there are many ways of effecting
such a mapping. Should values be encoded as tag content or attributes? How
should types be used? etc. etc.

I have seen people attempt to use XML as if it maps directly onto the type
mechanism of C++ or Java and plough on for years before they finally get the
fact that what is called a 'type' in XML is actually a type of a type and so
they have been talking complete nonsense.

The original design goal of XML was not to create a new data format, rather
it was an attempt to take out the worst and the most damaging and the
obviously insane features of SGML. XML succeeded in this mission without
introducing too much additional cruft. But somehow the inane prefixing
scheme did get introduced and that is a non-trivial pain in the patootie.

XML prefixing is an example of a bad idea that was turned into a worse one.
The original intent was not too bad but the consequences were.

XML achieves 'extensibility' by allowing one schema to include another with
a statement that essentially goes 'include XMLDSIG and prefix their tags by
xds'.

This would be OK, I guess if the variation that resulted was limited to the
schema level, but no, this did not happen. Instead, we require the data
structures in the final encoded data to also carry prefixes. Even in the
case that no ambiguity arises between the tags. SAML links to XMLDigSig and
XML Encryption and the scars where the parts of the Frankensteinian monster
are still visible in every SAML assertion. It is not possible in XML schema
to say 'include DSIG as if written out verbatim here'. It is not even
possible to say 'include DISG and always use this specific prefix'. No the
choice of prefix goes to whoever generates the final data.

As a result, XML parsers are indeed trivial to write. But only if you don't
have to track namespace prefixes at which point the whole thing becomes
much, much more than just knocking out a FSM which I can do for XML in about
30 mins and have working in an hour. Managing namespaces properly is non
trivial.

Similar objections apply to ASN.1. I can knock together an asn.1
encoder/decoder for a given ASN.1 structure quite quickly. Provided that is,
that the encoder is not having to deal with included ASN.1 objects, then the
problem becomes hard. Lots of corner cases start to show up and the whole
thing becomes a massive tooth ache and its time to call time on the whole
thing.

I have quite a lot of experience in XML and ASN.1 and I can knock together a
solution for JSON in far less time than I can spend explaining the intricate
gotchas and misery that are to be fond in ASN.1 or XML.

If we are working on a rich platform, we can of course use generic packages
that will assemble code for us. XML is natural to use on .NET because we can
simply write our data structures out in C# and call a method that will throw
out an encoder or a decoder for us. A masochist could no doubt do the same
for ASN.1. But on the smaller platforms, we don't have that option.

In particular, many, many compact S/MIME and TLS 'implementations' do not
process ASN.1 at all. Certificates are simply an opaque bag of bits that the
implementation does not understand at all. The public key data are
pre-extracted for them. Processing of CMS is vestigial.

This type of implementation is usually limited to generation of data
structures or consumption of data from sources that understand the
limitations of the receiver. But they are still quite common. In many cases
the people who code them are working on the basis of a suck-it-and-see
methodology in which success is declared when the code does not croak.

Such implementations can often be coded quite quickly and will work
acceptably well for the intended purpose. And are frequently used as an
existence proof for 'can do CMS in 4 hours' or the like. But nobody can read
the CMS spec thoroughly in 4 hours, let alone implement.