Re: Non-XML binary formats.

On Wed, 1 Dec 2004, David Ryan wrote:

>
>
> >> I have briefly looked at ASN.1 in the past and found it wasn't
> >> what I was looking for.
> >>
> >
> >     Yes. Most such statements start with something like "briefly
> > looked." The reality is that ASN.1 has always been able to do all that
> > XML
> > could do and it has been doing it for 20 years. The problem is that
> > people
> > typically look at it "briefly," get overwhelmed by what they consider
> > to be
> > complexity or a hard to read specification and then decide to do
> > something
> > simpler or easier to implement or proprietary. What they don't realize is
> > that there is a reason that ASN.1 is as "complete" as it is. That
> > "completeness" has been found to be required.
> >
> >
> >
> I've made the effort to go back and look over some of the ASN.1
> standards.  Again briefly, however, I think with enough knowledge to
> re-iterate that ASN.1 was not what I was looking for then as is now.  I
> reviewed the specifications at
> http://asn1.elibel.tm.fr/en/standards/index.htm as provided in an
> earlier email by Ed Day.  I was impressed with the XML Schema to ASN.1
> mappings, however, was surprised that no ASN.1 to XSD mappings were
> present.  I should also point out that XML and XML Schema didn't do what
> I needed, then or now.

An ASN.1 to XSD mapping was discussed when the XSD to ASN.1 mapping
was being created, but was rejected at the time.  During the past
year, this was been raised again, and was this time approved and added
to the current work program.  Don't expect a standard like this to appear
overnight, however.  There are many things that ASN.1 does that are not
supported by XSD.

>
> I've come from the direction of CORBA and other Remote Procedure Call
> architectures.  What I was looking for was a way of doing strong data
> type agreement between two systems that have not previously had any
> contact or been developed by the same parties.  This requires that the
> two systems are able to negotiate if they have the same data type
> formats dynamically; ensuring that their encodings also match.  This
> allows partial schema matching between two systems.  It requires that
> the schemas act more as dictionaries instead of schemas, or I believe
> the term in ASN.1 is modules.  It allows an individual application to
> build it's own vocabulary which meets its own needs, and then allows a
> client to discover if there is a match between its own vocabulary and
> the server's dynamically.  Argot was my solution for that problem.  If
> ASN.1 does allow such matching, I'd be interested in what part of
> specifications show this.

ASN.1 supports this capability via what we call Extensible Information
Object Set.  You can constrain a particular portion of a message (an
Envelope message perhaps with some "hole" for open content) using an
Information Object Set (to indicate what that "hole" should contain).
That Information Object Set can be dynamically changed (by addition or
deletion) at runtime to alter the nature of the content permitted.

>
> I keep returning to my original question to the list.  Is there no other
> data description and encodings available?  I suspected to atleast get a
> few responses.  I know of very simplistic standards like XDR.  I know
> there is an underlying model to CORBA with IIOP.  There must be some
> others out there that are not simplistic.
>
> > The telecommunications industry isn't going to rewrite their standards
> > overnight. Neither are the security folk or the network management people
> > that use SNMP.
> >
> >
> I think you'll find that with VOIP and other technologies it might be a
> matter of those technologies just disapearing in a similar way as the
> printing industry has done over the last twenty years.  Standards don't
> generally get rewritten, they just get replaced and become obsolete.

Are you saying you expect VoIP (which uses ASN.1) to disappear?  All
indications I see seem to indicate it is still expanding rather than
disappearing.

>
> >> It has had a long time to get attention, but obviously something is
> >> missing.  I don't know enough of the history of ASN.1 to know what
> >> that is though.
> >>
> >
> >     "Obviously something is missing..." This is just a vague suspicion
> > -- not the sort of thing that should motivate important technical
> > decisions.
> > It is the kind of emotional crud that has been typical of the anti-ASN.1
> > arguments all these years...
> >
> >
> It seems that calling the w3c simply arrogant and having proprietary
> pig-headedness has just as much emotional crud in it.  I agree that
> there is a huge wealth of knowledge in ASN.1 that should not be lost.
> However, I personally think they made the right decision in developing
> XSD seperately from ASN.1.  I don't particularly like XSD, and it
> probably could have learnt a lot more from ASN.1 than it has.

ASN.1 did influence some aspects of XSD.  Before XSD 1.0 was released by
the W3C, there was a gentleman from the USGS that was on the XSD
committee, who was attending several of the ASN.1 meetings in order to try
to influence both to produce compatible XML documents.  Some features of
ASN.1 did make it into XSD (although in slightly different manners to how
they worked in ASN.1).

>
> Maybe my question was wrong in the first place.  While the actual
> encoding is important in my scenario, it is actually the flexibility of
> the structure definition or type system which is more important.  XSD is
> one,  ASN.1 is another.  Argot is my proprietry format.  Is there any
> other type systems that have been developed?
>
> Sorry if I've taken this mailing list off topic.  Having heard some of
> the issues and reignited the old ASN.1 debate, I'd be interested know
> what direction the XML Binary Characterisation working group are
> currently heading?

I am a member of the ASN.1 committee (which is joint work with ISO/IEC
and ITU-T), and am also a member of the W3C XML Binary Characterization
working group.  We are finishing gathering all of the background
information we need, and have yet get into the real heavy discussions
about which direction to recommend the W3C go on this.

----------------------------------------------------------------------------
Paul E. Thorpe                                 Toll Free    : 1-888-OSS-ASN1
OSS Nokalva                                    International: 1-732-302-0750
Email: thorpe@oss.com                          Tech Support : 1-732-302-9669
http://www.oss.com                             Fax          : 1-732-302-0023

Received on Tuesday, 30 November 2004 17:42:37 UTC