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