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:
> Robin Berjon wrote:
>>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. 
> 	I propose that the MIME type name you should use in this case
> would be:
> 	image/svg+foo
> 	i.e. you've got an abstract type "SVG" which is encoded or
> serialized according to the "foo" rules. Just as normal practice today
> means that image/svg+xml is abstract type "SVG" encoded using XML
> rules.
> 	Foo, BER, PER, CBXML, and XML are all concrete encodings.
> Given that +xml made sense for XML and given that there isn't anything
> conceptually special about XML as an encoding type, what works for XML
> probably works for other encoding rules as well. A nice attribute of
> this system, documented and justified in RFC-3023, is that it
> distinguishes quite well between the abstract and the concrete
> syntaxes. It is, I believe, vastly superior to requiring that a new
> type (such as "image/svgfoo") be defined.

I'm not saying you're necessarily wrong, but allow me to continue down 
the "it's not so simple" path.

What you describe might work for specifications defined on top of the 
Infoset, with great care to do so. I say *might*, because you'll still 
find people to disagree. Either way I picked SVG because it's not 
defined based in the Infoset, but in terms of syntax.

SVG isn't a model encoded as XML plus some micro-parsing bits. You 
mention an "abstract type SVG encoded using XML rules". There is no such 
thing. You may think there is, but you won't find it in the spec.

But could you decide to ignore this fact as purely academic and pick a 
schema (which current you'd pretty much have to write) to encode the 
Infoset or PSVI extracted from SVG as something else? Well yes. But then 
you'd be having all the paths and style and a bunch of other things as 
strings, when they really are structures. Users won't be happy with that 
(I know) since it removes a lot of benefits of having a binarised 
format. Plan B: after reading the spec in depth it strikes you that what 
comes closest to being an "SVG Abstract Data Model" is the SVG DOM. It's 
probably not perfect, but close, likely close enough. Hmmm, but wait, 
the DOM isn't compatible with the Infoset/PSVI/DM so that generic 
Infoset/PSVI/DM you got? It doesn't work.

I'm not complexifying this for the sake of argument, all that I have put 
above are objections that happen in real life. Yes, it's very much 
possible to define a solution that'll make you and your 
friends/customers happy, and I could have a different solution that 
would make me and my friends/customers happy, and oh there's another one 
over there... but what we want is interoperability and genericity, and 
having 42 ways to encode SVG just won't do.

Ah, and all this just to agree on a silly mime type! ;)

There's now a wealth of experience out there on ways to "binarise XML". 
But there are issues that need to be agreed upon. I guess now would be a 
good time to try and get all those people together to figure out if they 
can agree, and if so on what.

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