On Fri, 18 Jan 2002, Graham Klyne wrote:
At 08:51 PM 1/17/02 -0500, Ian Graham wrote:
MIME really doesn't give you a nice way of defining multipe properties for
a single resource, other than the media features extension described
in RFC 2912. Using this extension (Designed for a different purpose, BTW)
you could write something like:
Not so very different...
Content-Type: text/xml;
Content-features:
(& (primary-namespace="uri1")
(secondary-namespace="uri2")
...
)
The question then is -- does that really give you anything particularly
useful over text/xml+whatever? Once I started to think through some
uses, I honestly couldn't think of a compelling advantage ...
... it gives fine grained content feature description with sufficient
detail to form a basis for content negotiation. The work had (some of)
its roots in recognition of the fact that the content type alone was
insufficient for effective content negotiation in HTTP.
....
(I'm not suggesting all this is relevant to the current debate, just trying
to answer the question you raise.)
I do agree, but at the same time I couldn't, in the context of projects I
was working on, find a use case that cried out for this approach. In many
cases it seemed easier to user XML messaging to do the content
negotiation, and use a 'base' XML dialect to bootstrap content
negotiation, for example. Thus my 'no compelling advantage' comment.
The arguement for the current approach over this (or any other) extended
approach was apparently based on pragmatics: most existing MIME type
handlers only pay attention to the content type, and moreover ignore any
property extension added to the field (e.g., content-type:
text/xml;namespace="foo") Thus, the application/xml+svg was the 'easiest'
solution that would work with a minimum of fus with essentially all mime
handlers.
(I'm paraphrasing this argument from correspondence by Simon St. Laurent
and "MURATA, Makoto" -- I accept full blame for any misrepresentations)
Best --
Ian