One alternative - not necessarily one I am advocating, but just listing for
completeness - is to use a similar approach but swapped round:
image/svg;ContentLanguage=xml
I favor something like this. it seems like it will interact more
cleanly with content negotiation mechanisms (as opposed to those
mechanisms having to acquire new pattern-matching facilities)
it's true that as MIME is architected the parameter space is on a
per-content-type basis. but I don't see any great harm if we define
some global parameter name space (say, parameter names that begin
with "$" are global). Then we could do something like:
content-type: image/svg; $superclass="application/xml"
it's true that a lot of existing content-type dispatchers wouldn't
know how to deal with the parameter, but that doesn't seem like
such a big deal because it's easily added to the few MIME handlers
that know about XML. similarly there are content-type labellers
that don't know about the concept of parameters but this provides
an opportunity for them to get fixed. and since this is only a
hint and the complete type is still specified in the foo/bar
portion of the content-type, the system can still "work" even
in the absence of the $superclass label.
Keith