Re: Non-XML binary formats.

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

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.

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.

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

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?

Regrards,
David Ryan.
www.einet.com.au

Received on Tuesday, 30 November 2004 13:01:54 UTC