ietf-822
[Top] [All Lists]

Re: Finishing the XML-tagging discussion

2000-03-20 12:24:19
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
usage.

If we absolutely have to do this with a separate piece of information, I
would
opt for a content-feature tag. That way there's a clear delineation
between
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
purposes.

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
field.

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

    image/svg

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
there.

                                Ned