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] ASN.1 is an XML Schema Language (Fix those lists!)and Bina

[ Lists Home | Date Index | Thread Index ]

Why does it seem to be me that answers all of this!  And much of these remarks 
and discussion are diverting strongly from "binary XML", to which we should 
return!  See comments below.

John L

tpassin@comcast.net wrote:

> According to some things I have read or been told, ASN.1 was originally developed for people - people communication,

That was certainly a view in mid-1980.  It evaporated totally when tool vendors 
appeared on the scene.  And you are right that some of the syntax was originally 
designed more for human consumption and readability than for machine parsing. 
That has been addressed as much as possible over the years, and is certainly not 
a problem with most of the stuff in use today.  (If you want an opposite view, 
much of the recent stuff errs very much on the side of machine processability, 
at the expence of human-readability!  But my colleagues certainly do not agree 
with me on that!  They absolutely want syntax designed primarily for machines!)

  to let them explain schemas to each other.  Probably because of that, it 
turned out to be a bear to parse.

I do not know if the residue of this still plays a role, but full ASN.1 has an 
awful lot of syntax features.

> Maybe it is like XML Schema - no one has yet implemented every feature correctly (or have they by now?).

I wish someone else would wade in, but I believe that at least one vendor has 
implemented ALL of ASN.1, in totality, and professionally, and correctly.

I myself wrote an ASN.1 to XML Schema translator - __very__ incomplete and 
simple-minded, though it handled most

ASN.1 to XSD is easy, because ASN.1 is essentially simple and straight-forward 
(XSD is NOT!  All the xsi: stuff .....).  XSD to ASN.1 was a major challenge, 
and X.694 a major achievement (here I am blowing other's trumpets - my role in 
that technical work was minor.)

of the schemas we were dealing with (and the xml format described by the 
resulting xsd schema was not XER).

There was a proposal to standardise an ASN.1 to XSD mapping that would produce 
XSD that would be in agreement with ASN.1 XER, but that standardisation proposal 
was not supported by tool vendors "Why should we provide a mapping out of our 
supported notation?", but I know that one tool vendor has such a product for 
internal use, but I do not know if it is being marketed.  Personally, I always 
felt this was a wrong stance, as if the decision is to use ASN.1 or XSD as the 
master definition of a format (and map to the other), then if you can only map 
one way, you are going to go for the one with the defined mapping to the other. 
  There are currently too many different mappings (none standardised) from ASN.1 
to XSD, only one of which is reversed by the standardised X.694.  But this 
situation may well change.

There are many wrinkles and optional features and special cases and defaults to 

You mean more than there are in XSD?????  You have to be joking!

> I think that some of the sophisticated encodings like PER are very hard to get right and complete,

We all have our views.  I have to admit that I was one of the main architects of 
PER (now cast your stones!).  It DOES have a lot of uniform features (such as 
the way extension bits are handled), and if you recognize the philsoply of "do 
what a sensible human-being would do" as the central philosopy, I think it is 
pretty understandable.  It got slightly confused/complicated by the ATN people 
that said "we really want minimum bits on the line, not the trade-off of 
"minimum bits where it is sensible".  I guess that is basically the issue.  PER 
is an ENGINEERING solution.  Not a COMPUTER SCIENCE solution.  In other words - 
do what looks right, not what looks pretty.  But I am biassed on this one!  I 
will field any detailed technical criticism of PER without hiding behind "would 
others please respond" - as I do with tool issues.  But this is getting VERY off 
the "binary XML" thread - not that I want to stifle discussion.

too (I have never looked into these encodings, so have no first-hand experience 

Rumours that are propagated without inspection are a pain - for any language 
specification.  Of course what "the general uninformed public" thinks IS 
important, but it would be good if discussions on this list reflected informed 

(Having said that,  getting rumours and prejudices aired and discussed - and 
hopefully defused - is clearly important.)

Let me finish with a repetition of the original thread:

Defining message content as a set of abstract values with a defined semantics, 
divorced of concrete representation (infortunately there are many different term 
s used for this distinction, but I hope it is understood) is very important.

It allows mappings (specification of encoding rules and APIs) of a single 
specification into multiple language data structures and into multiple transfer 
formats, and allows the production of tools to support all these mappings.

It was a major development in the specification of computer-to-computer messages 
in the 1980s when this was recognised.  In terms of hype, we have take a big 
step backwards recerntly.

I attach an academic(!) discussion of this issue.

John L

> Cheers,
> Tom P
>>There seems to be quite a few half-baked Open Source tools for ASN.1 
>>that seem to have stopped at supporting BER and a subset of the abstract 
>>syntax that they deemed useful, but never its entirety. Do the ASN.1 
>>folks consider this a problem? It certainly has caused me to try and use 
>>it, and give up in the past for I didn't have time to fix the tools. 
>>What is the generally admitted reason for this? Spec complexity? Lack of 
>>interest? Something else?
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>

    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Development Services Ltd)
    1 Blueberry Road
    Bowdon                               j.larmouth@salford.ac.uk
    Cheshire WA14 3LS
    Tel: +44 161 928 1605		Fax: +44 161 928 8069

A shorter history of protocol specification.zip


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS