Re: ASN.1 and XML

["Simon St.Laurent" <simonstl@simonstl.com>]

On 24 May 2001 17:22:43 +0100, Al B. Snell wrote:

> The only edge XML has over ASN.1 encodings is that XML has hype, and
> therefore lots of available toolkits...

Hmmm... a lot of those toolkits appeared in advance of the hype, and
were built on too many years of SGML experience in the 'pre-hype' days.

> 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.

And is that process something you'd like to explain to a large number of
Web developers with scripting skill but no grasp of codecs?  Is creating
and processing ASN.1 (in your mind) nearly as accessible as creating and
processing XML?
 
> 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.

There's really nothing technical in data representation that hasn't been
done before.  Making data representation accessible to a much wider
range of developers is pretty clear new, however, and worth the
attention you appear to dismiss as hype.

> 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.

One of the big wins of XML over ASN.1 is that you need much less than
the facilities you describe above. You don't need a schema to get real
work done.  You don't need a disassembler to inspect your information.
You don't need to ponder encoder modules or compile-time choices much of
the time.

> 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.

Thanks, but XML without the element/attribute names sounds like a
roadmap with no roads on it to me.  And PER sounds almost as exciting as
the PSVI.

> Another win of ASN.1 over XML is 15 years of practical experience using it
> in the real world. That's hard to beat :-)

Uh... SGML goes back way before my time.  1986 for ISO, 1960s for early
development.  XML wasn't built of whole cloth.

> 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.

And, uh, why exactly is it so lacking in hype if it's so easy to learn.
Microsoft does use ASN.1 for a lot of different projects, so I don't
think it's that...

> 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.

Wow.  So you really think ASN.1 is the way, even though that paragraph
demonstrates how far behind ASN.1 is as far as reaching a wide audience
of developers.  Sounds like your annoyance has a lot more to do with
accessibility than with hype.

> 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. 

Great.  It's nice to know we're heathens.

> 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*...

Yeah, well, a lot of us don't have much admiration for the finer things
in life, and would rather devote our lives to the advancement of
technologies which focus on humans as much as on machines.  Remember,
we're heathens.

> 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!

Tools-available reflects accessibility and motivation.  XML got its
initial start from a group of deeply motivated and pretty thoroughly
experienced developers who seem to have wanted to create something far
more accessible to people with less experience than themselves.  

I don't think XML was ever about solving data problems perfectly, but
rather about creating a flexible system in which programmers and even
document authors could walk up, kick the tires, look under the hood, and
get work done without huge barriers between them and the data.  Textual
markup does really well at that...

Personally, I get excited about the potential of doing more with less.
Seems to be a common tendency on the Web.