RE: text/xml for SOAP (and XP) considered harmful

> > Why not say something like
> >
> >  Content-Type: text/xml;
> ns="http://schemas.xmlsoap.org/soap/envelope/"
> >
> > where the ns parameter specifies the ns identifier of
> outermost element.
>
> 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.

I am sorry that I haven't seen this discussion but I am afraid I don't
understand the reasons you put forward. You previous spec (RFC 2376) as
well as this ID already says that using the charset parameter is
"STRONGLY RECOMMENDED" and it goes to great length to promote using this
parameter. Why would a "ns" parameter as I suggested be different (which
is not defined as part of MIME per se but as a parameter on any given
media type)?

Yes, of course an XML document may contain more than one XML NS but
could you tell me how this is captured by, for example "text/rdf+xml"? I
note that your draft says

   This document recommends the use of a naming convention (a suffix of
   '+xml') for identifying XML-based MIME media types, whatever their
   particular content may represent.

If I want to indicate that something is RDF, I use the XML NS identifier
as a mechanism for indicating that the content represents (or is) RFD.
What benefits would a shortname give me that the URI doesn't? The cost
of this shortname is pretty high in terms of maintenance overhead,
central registration, and having to parse a new syntax.

Before anybody starts to require introducing a centralized registration
mechanism for something that has been explicitly defined to be
decentralized *and* introduce a new syntax (using the "+" as separator),
you need to have a very good reason for doing so. The arguments you
bring forward here do not meet this bar.

If the point of your draft is to bridge the media type mechanism with XML NS
then there are plenty of ways to do so without a new syntax and without
central registration.

PS: The draft fails to indicate the appropriate forum for discussion of these
issues but please feel free to forward this mail as appropriate.

Henrik

Received on Wednesday, 13 December 2000 08:23:59 UTC