suppose we were just to have something like:
Content-type: image/svg; representation="xml"
where "representation" is just a plain old MIME parameter.
would you object to something along these lines?
Yes. Most of the problems I have with global parameter still apply to this
If we absolutely have to do this with a separate piece of information, I
opt for a content-feature tag. That way there's a clear delineation
when feature information is or is not present, and we don't mess up MIME
parameter space. And we need the feature tag anyway for negotiation
hmmm. my view of the example above is that XML is being used as the syntax
but the semantics of the blob being passed are still SVG semantics.
I agree, but I fail to see how this changes things. I was talking about
having a media type other than application/xml _and_ a content-feature
at the risk of seeming insensitive with the exception of "text/xml", i would
never expect to see a subtype of "xml" for any media type.
Again I agree. People are going to register separate media types for
the XML-based things they come up with. (This is already hapening.)
of course, taking
that line, i suppose that the example above should simply be
and that the processing element for that application should already know the
possible syntaxes that it could encounter.
This is the crux of the -xml proposal. All it says is that if SVG always has
XML syntax the name image/svg-xml may be used to indicate that in the media
type name and that the -xml suffix won't ever be used on anything that doesn't
have XML syntax. Nothing more and nothing less. It doesn't require that this
naming convention be used for all things XML, it says nothing about matching
such names as part of content negotiation, and it doesn't affect whether
or not a given XML variant gets its own media type name or not.
It seems that a lot of people are reading vastly more into this than is