application/something+xml (was text/xml for SOAP (and XP) conside red harmful)

Thank you for your responses.  I will reply to some of the other points in a
separate message, but I am puzzled by your response to my question
reproduced below:

Andrew's question:
> b.	Existing implementations should indeed be considered.  Is it
> asserted that all existing implementations process
> "application/something+xml" in the intended way?  Or is it asserted that
> many existing implementations can be adapted to the more elaborated form
of
> content type, but cannot be adapted to use parameters?

Larry's response:
>The important way in which existing implementations are considered is
>to keep out of their way, and vice-versa. Not just "existing
implementations
>of SOAP, ebXML, WebDAV", etc., but existing implementations of MIME
>infrastructure.

I don't entirely follow how this is an answer to the question of whether
existing implementations can be adapted to the more elaborated form of
content type, but cannot be adapted to use parameters.  Do you mean that
existing implementations of MIME infrastructure will fail to recognize
"application/xp+xml" and so will not treat it equivalently to any of the
millions of other uses of XML that will merely be marked "application/xml"? 

If so, is it sufficient to use a form of "something+xml" to distinguish this
from mere XML (whatever that is) or is the intent that the "something" is
registered somewhere so that it can be recognized and used for processing
decisions?  If so, does that mean that all potentially widespread uses of
XML should register somewhere their use?  (e.g. WAP, ebXML, BizTalk etc.)?
What should we do if BizTalk or ebXML use SOAP or XP
("application/ebXML+XP+XML"?)?  If there is a registry, should it be a
registry of simple names (e.g. "XP") with a single, centralized authority,
or should it be a mechanism that, like URLs, allows decentralized, federated
authority? 



-----Original Message-----
From: Larry Masinter [mailto:lmnet@attglobal.net]
Sent: Tuesday, December 26, 2000 3:59 PM
To: Andrew Layman; xml-dist-app@w3.org
Subject: RE: text/xml for SOAP (and XP) considered harmful


 > I have not seen a reply regarding the points below.  Modestly, I think
they
> are good points and quite relevant to the continuing discussion, so I
bring
> them to your attention again.

Here is a reply; I don't think this is a new reply, but it summarizes
replies made before.

> The proposal to use an elaborated form of Content-Type, e.g.
> "application/soap+xml",  does not solve a major problem of content types,
> namely that they are not tied in with URIs and consequently are not
> manageable or extensible in a decentralized way.

There are many problems that using "application/soap+xml" or
"application/xp+xml" as the Content-Type of SOAP/XP messages does not solve,
but that doesn't mean that they aren't the most appropriate Content-Type
to use.

In this case, I don't know what it would mean to "tie" the Content-Type
to a "URI" or what requirement would lead one to believe that XP should
be described in a decentralized way, or in a way that the content-type
itself were more extensible than the existing extensibility of using
content-types (namely, that anyone who wanted to define the 'scrub' protocol
could register application/scrub+xml and use it instead of
application/soap+xml).

There are some elements of what it means to "speak XP" that need to
be agreed upon in order to have minimal interoperability. That's why
there's a standards group, rather than having each vendor go off
and implement their own thing and just forget about this mailing list.

The only question before us is "what content-type do we use when we
are using XML as agreed upon by this standards group", and the proposal
is to define one (say, application/xp+xml) specifically for that purpose.
This would allow one, for example, to distinguish "XP" from "SOAP/1.1"
and any of a dozen other protocols that operate by POSTing text/xml
bodies. The role of "Content-Type" in Internet protocols layered on
MIME is relatively minimal, but worth getting right.

If there is some other problem we should also be solving, could you
please elaborate?
>

> Regarding a specific proposal that would, in effect, use a URI in place of
> "soap+" in the above example, MURATA Makoto wrote
>
> "This has been already discussed in the IETF-XML-MIME mailing list,
> and has been turned down.  First, a document may contain more than
> one namespace.  Second, existing implementations of MIME does not
> use parameters."
>
> Concentrating on the reasons given, which must be the reasons by which we
> judge the proposal, and not on the fact that the point has been discussed
> elsewhere,

Of course. It's only that it seems fair, as you are reviving points
previously, to note that the responses were also given previously.

> a.	The essence of the idea of using a URI in lieu of "+something" is
> not that it must be the element name of the root element, but that it is
an
> identifier from the universal resource identifier namespace, and so
operates
> with the same decentralized authority that has proved essential in URLs,
> SOAPAction headers and XML Namespaces.

I don't think we have any way to take "the essense of the idea" and
create a concrete proposal that is also consistent with the way that
MIME media types are actually defined and used. As you point out, there
are already multiple mechanisms in place for extensibility. The only role
of the "content-type" at all in XP is to distinguish XP traffic from
other traffic that might otherwise inadvertently traverse the same
transport/transfer protocol path.

> b.	Existing implementations should indeed be considered.  Is it
> asserted that all existing implementations process
> "application/something+xml" in the intended way?  Or is it asserted that
> many existing implementations can be adapted to the more elaborated form
of
> content type, but cannot be adapted to use parameters?

The important way in which existing implementations are considered is
to keep out of their way, and vice-versa. Not just "existing implementations
of SOAP, ebXML, WebDAV", etc., but existing implementations of MIME
infrastructure.

Were XP to be transport over something other than HTTP, a "content-type"
parameter might not be necessary at all.

Received on Wednesday, 27 December 2000 14:05:49 UTC