Ned,
When you say:
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'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.
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.
Finally, I note that one of the objections raised on the XML-MIME list was
a desire to avoid using content negotiation protocols in order to discover
that a document contains XML. I agree. I observe that neither the CONNEG
framework, nor the 'Content-features:' proposal, is a negotiation protocol
per se. They are mechanisms for describing content features and handling
capabilities, which may be used as part of a negotiation framework, but
studiously avoid defining any negotiation protocol.
#g
--
At 01:00 PM 3/11/00 -0800, ned(_dot_)freed(_at_)innosoft(_dot_)com wrote:
I've really got to agree with Keith here; this is a mess and I oppose
the direction it is taking. If XML-ishness needs to be called out as
a property of a body part, it should be separated out as a parameter
of some sort, or made a new field, not embedded as part of the name
of a content-type. I know where in our code I can dispatch off of a
parameter or a new field; that's easy. Dispatching off part of a name
would be grotesque.
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.
There are mechanisms in MIME to call out properties like this. Why
are we trying to embed this particular one in the name instead of
using the mechanisms that MIME provides?
Because upon examination none of them seem even remotely correct for the task
at hand. My conclusion is that if you want to do this, this is right way.
Also, Ned said, long ago in May 1999, in the XML-MIME list:
The long and short of it is that I don't see either extreme position on this
issue as tenable. The notion of "all XML goes under the application/xml media
type and a different mechanism is used to distinguish different instances of
XML usage" is a nonstarter, and so is "every little twiddle to something done
in XML gets a new media type". I also don't think that XML is even close to
mature enough for us to attempt to establish definitive rules for when a media
type is needed and when it isn't.
------------
Graham Klyne
(GK(_at_)ACM(_dot_)ORG)