> All of these approaches were explored in depth already on the XML-MIME list.
> All of them have major disadvantages over the tagging scheme presently
> proposed. I ended up in strong opposition to all of them, whereas I could find
> no good reason to oppose this approach.
Was the 'Content-features' + CONNEG proposal one of those that you strongly
opposed for this purpose? If so, I'd like to know why.
I believe this one was discussed. And I agree that it's the best of a bad lot.
However, I still oppose it. The problem with this proposal is that all it
does is push the problem around; it doesn't solve it.
Specifically, in order for this to work sending agents have to generate a field
saying "this thing is XML". In order to do tis they have to have a list of all
XML-based types. And this is exactly the list we're trying to avoid having.
Compare this with embedding this information in the content-type. There's
already a list of (some file characteristic)->content-type mappings in most
MIME applications. So no new list is needed. The information simply gets
embedded in the existing list.
Now, I know that the conneg folks have high hopes of being able to pass conneg
information from applications generating media types to the applications that
move them around. However, existing infrastructure rarely supports this sort of
thing at present. And if you believe that knowing something is XML is useful,
waiting for this infrastructure to appear just isn't reasonable.
I am also less that fully comfortable using conneg fields to carry around
information that is an immutable property of a given media type. My feeling
is that conneg is for the stuff that's associated with a given instance
of a media type.
I've briefly reviewed the XML-MIME discussion, but haven't been able to
spot anything that argues against this approach, except that there was an
expressed requirement for a very "simple" way to detect XML content.
Its basically the same as the argument against putting a "this is XML" tag in
the content-disposition field. It's a much better semantic fit than
content-disposition, but that's all.
The Murata proposal goes some way toward this and, like you, I see it as
"mostly harmless", even though it may be messy at times. But I don't think
it can ever be a complete solution: I cannot see that it will be
reasonable to enforce that all processors will reliably recognize XML in
this way. But a simple mechanism --like Murata-- that can work much of the
time may still be useful on occasion. I refer in particular to your
comment quoted at the end of this message.
Where this leads me is: what is an appropriate mechanism for describing
for precisely the XML use of some content? I offer something along the
lines of:
Content-features: (Schema="<URI>")
(Where <URI> can refer to a DTD, XML-schema, RDF-schema or other
XML-related document schema.) The CONNEG framework can allow this to be
extended to deal with compound documents that are part-XML, or to compound
XML documents that use different schema in different parts. I also believe
this can be designed to interwork cleanly with some ideas being considered
for W3C CC/PP.
Well, I would have hoped that the schema would be derivable from the content
without the need for a conneg tag. That is, given the labelling in the
content it should be possible to construct a URN automatically that tells
you where to look for the schema definition.
And again, unless you're dealing with application/xml, this seems like
an immutable property of the type.
Ned