Again, this can be handled by using content-negotiation. It would be pretty
easy to add a conneg type that would describe the type of XML that you are
passing, without breaking the example I gave for protocols that don't do
negotiation.
The need for content negotiation in certain circumstance seems real -
maybe, just maybe, I've extracted this much of a concession.
The question then becomes whether it is better to describe content in one
concise description (the MIME type) or using separate protocols.
1) What are the real 'costs' of adding a new top-level MIME type?
It has been reported that there is deployed software that has to be changed
to deal with new top-level types (a big design botch in my opinion). This
came up when the model top-level type was added.
There's also the cost of writing it up and getting it standardized. It is
likely that there would be strong objection to defining such a type (I
certainly would object because I don't see this as being properly orthogonal to
several of the existing top-level types).
1a) What are the costs of adding xml- as a prefix to XML-based MIME types?
(Rick Jelliffe's proposal.)
There are actually three possible proposals in this space:
(1) Add a "xml." facet and corresponding registration tree. Again, this
requires writing a specification, and it is likely to be controversial
because this doesn't meet the criteria for a new registration tree and
also isn't orthogonal to existing trees.
(2) Recommend/require that the names of XML-based types have "xml-" after
the registration facet. This could be done simply by adding some text
to this effect to a revision of the XML in MIME document -- once in place
the media types reviewer (me) will see to it that appropriate names are
selected for new types.
(3) Recommand/require that the names of XML-based types have "-xml" at the
end of the name. This is the same as (2) in terms of effort, but might
be a win in that matching a suffix might be easier/cleaner to do in
some contexts (the beginnnings of these strings are grotted up with
registration tree information).
2) What are the real 'costs' of creating separate content-negotiation
protocols?
The costs are that there are contexts where you're unlikely to see the
ability to use such things in the forseeable future, and where you'd
really like to make choices based on knowing the XML variant in use.
I'm afraid that I'm unconvinced that the costs of 1 are greater than the
costs of 2. Are there genuine compatibility issues, or is this just
philosophical opposition?
The former, according to reports we've gotten in the past.
Ned