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] Patented XML Compression Techniques (WAS RE: [xml-dev] Bin

[ Lists Home | Date Index | Thread Index ]



> -----Original Message-----
> From: Robin Berjon [mailto:robin.berjon@expway.fr] 
> Sent: Wednesday, August 06, 2003 04:59
> To: Alessandro Triglia
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Patented XML Compression Techniques 
> (WAS RE: [xml-dev] Binary XML == "spawn of the devil" ?)
> 
> 
> Alessandro Triglia wrote:
> > - there is no reason that standardization in this area will 
> increase 
> > the costs of participation for smaller companies and individual.  
> > Several ASN.1 langage tools are freely available.
> 
> Could you please provide pointers to those tools? 

http://asn1.elibel.tm.fr/en/links/#tools


> I've tried 
> several times to 
> get my hands on ASN.1/XML tools that worked but so far the 
> results have been 
> terrible, especially when looking for early implementations 
> of X.694. 


The web-based tool present on the asn1.elibel.tm.fr site is an
implementation of an early draft of X.694.  The X.694 document is currently
under ballot and contains several known errors that will be corrected.

As for ASN.1/XML tools in general, note that the new ASN.1-based standard I
mentioned in my previous message will not require the use of the XML
Encoding Rules (BASIC-XER or EXTENDED-XER) but only the use of PER (or
perhaps BER).  Older ASN.1 tools can be used, so long as they support PER
(or perhaps BER).

It works more or less this way.  First, an XSD schema of a message part or
header block has to be translated to ASN.1 using X.694 (this will usually
require the use of an X.694 tool, except for very simple schemas).

Once an ASN.1 schema equivalent to the original XSD schema is available, the
data will be normally encoded in PER (or perhaps in BER).  Therefore, it
will be possible to implement a client or a service using the ASN.1
definitions with PER encodings, and with no use of EXTENDED-XER.

The XML encoding rules will be necessary, instead, whenever ASN.1 is used as
the schema language and one wants to exchange XML rather than PER.

In addition, the XML encoding rules will be very convenient when converting
XML messages from/to PER-encoded messages, but it is still possible, for an
application that knows the schema, to convert messages without using the XML
encoding rules.  More complex (and more generic) applications will have to
use X.694 plus EXTENDED-XER for handling the conversion in a way that
doesn't require previous knowledge of the schema, or for handling XML and
PER in a uniform way.


> The tools 
> either don't work, only support a very limited subset of XML 
> Schema, don't have 
> standard XML APIs, etc. It would be nice if some of us could 
> assess the quality 
> of the later ASN.1 specs before the workshop.


I am not sure this will be possible, because the documents are currently
under ballot in ISO and cannot be made public at this time.

Alessandro Triglia
OSS Nokalva


> 
> Thanks,
> 
> -- 
> Robin Berjon <robin.berjon@expway.fr>
> Research Engineer, Expway        http://expway.fr/
> 7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488
> 
> 





 

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

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