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