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] ASN.1 is an XML Schema Language (Fix those lists!)andBinar

[ Lists Home | Date Index | Thread Index ]

Bob Wyman wrote:
> 	The issue you mention, is with the encodings -- not the
> abstract syntax. Certainly, an XML parser can't "read anything
> produced based on" some encoding other than XML. It doesn't matter if
> that non-XML encoding was produced by something from the ASN.1 suite
> or something entirely different (e.g. XDR).

Yes, I completely agree with that.

>>If all you have is an ASN.1 schema, and you're on the 
>>receiving side, you don't know what you're going to get. 
>>If it's an ER you don't know about you won't read it.
> 
> 	Right. Once you have choice, you need to have a way of
> discovering what choices were made. You need a way to tag an encoding
> with its type. This is not a problem unique to the encodings defined
> by ASN.1. The same problem will arise with *any* alternative encoding
> of XML data -- including all the various proposals for a "binary XML."
> This will even be true if "binary XML" is simply zipped text.

Agreed. Hence the need for discussion.

> 	These days, we tend to use MIME types for this sort of thing.
> That's why I've begun a discussion on the asn1xml mailing list to work
> up a proposal for registering MIME types for the various encodings
> defined in ASN.1 land.

But that's one area where it might not be that simple. Say you have an 
"alternate encoding", be it PER, BiM, or CBXML (let's call it Foo), and 
you're sending an SVG document, which normally travels as image/svg+xml. 
Do you want it to travel as application/foo, as image/svg+foo, or still 
as image/svg+xml but with a Content-Encoding header of "foo" (as it is 
done with gzip)? The first one means you lose the information that it's 
SVG, which is a pity because that's important information. The second 
one means you create a new mime type for all the +xml mime types, which 
isn't ideal. The third one means you consider your "alternate encoding" 
to be an encoding of XML similar to gzip, when in fact it's a different 
type of encoding and you likely open up the data model vs just syntax 
debate.

-- 
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway      http://expway.com/
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