W3C home > Mailing lists > Public > public-xml-binary@w3.org > December 2004

Re: Non-XML binary formats.

From: David Ryan <david@einet.com.au>
Date: Wed, 01 Dec 2004 13:48:22 +1100
Message-ID: <41AD30F6.20104@einet.com.au>
To: Paul Thorpe <thorpe@oss.com>
CC: bobwyman@pubsub.com, "'Stephen D. Williams'" <sdw@lig.net>, public-xml-binary@w3.org

Paul Thorpe wrote:

>>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 went back to the standards page and had a closer look at the X.681 
Information Object Specification.  I assume this is the correct 
specification to review?  The specification while full of detail does 
look like it will require some heavy studying of the other ASN.1 
standards before I can fully understand its aims.  However from what I 
read, this doesn't exactly meet the needs I stated above.  It looks like 
an addition to ASN.1 and does not go to it's core.  This also doesn't 
seem to dictate how you would encode the information object 
specifications.  The aims for Argot and its Remote Procedure Call system 
was to allow the full data type vocabulary and encodings to be matched 
before communicating with them.

The approach I took with Argot was to create a fully self referencing 
binary description format.  Each definition is fully described by other 
elements defined in the dictionary using a binary description.  This 
makes the description size small and more importantly the library size 
at the end points small.  By keeping every element self referencing a 
client/server interaction can bootstrap the conversation by ensuring 
that the description formats are the same.  I think using an ASN.1 
Information Object Specification based solution would not be able to 
reach the same elegance in deriving a solution, or meet the size 
requirements.

Does ASN.1 allow the description of its types to be encoded using one of 
its encodings like BER?  From what I've read so far, the ASN.1 language 
is strictly a text based language.  I've found the benefit of having the 
type descriptions also in binary allows the client to require no text 
based parser.  This has resulted in a very small marshalling system.

>>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.
>
>  
>
Maybe using a telecommunications example was a bad choice.  I agree that 
standards don't disapear, however, they do become less important. CORBA 
is another example.  It will continue to be used in systems now and in 
the future, however, I don't see many enterprise organisations picking 
it up for new integration projects.  This is also true of ASN.1.  The 
current flavour is XML and XML Schema.  If XBC WG put together a 
solution that satisfies the use cases stated that new standard is likely 
to become the new flavour of XML.  I think that will be the case for 
both the use cases stated and many other places text is used currently.  
Now, if ASN.1 is what XBC WG end up putting forward, then maybe there 
will be a big role for ASN.1 in the future.

>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.
>
>  
>
Is this mailing list the best place to keep updated with the work of the 
XBC WG?  I'll be very interested to see which direction the working 
group take the specification and recommendations.

Regards,
David Ryan.
www.einet.com.au
Received on Wednesday, 1 December 2004 02:46:34 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 1 December 2005 00:07:42 GMT