[
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
handle.
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
here).
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
opinion.
(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
England
Tel: +44 161 928 1605 Fax: +44 161 928 8069
A shorter history of protocol specification.zip
|
