W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

Re: text/xml for SOAP is incorrect

From: Jacek Kopecky <jacek@idoox.com>
Date: Tue, 18 Sep 2001 18:54:03 +0200 (CEST)
To: christopher ferris <chris.ferris@Sun.COM>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0109181809530.16642-100000@mail.idoox.com>
Chris, I agree text/ is inappropriate.

RFC 3023 is named XML Media Types and I don't see how any general
MIME dispatchers with an XML handler installed (just like a jpeg
handler) could recognize the prefix +xml.

In other words, I don't think MIME dispatchers usually allow for
registering of handlers by subtype substring or even for example
a regular expression. The usual, IMHO, is installing for things
like, a/b, a/* and */*.

I don't think an implementor of a general MIME dispatcher would
even try to find, whether there is some other RFC (like 3023)
besides the MIME RFCs that they are implementing.

I've skimmed through appendix A of RFC 3023 and I feel like it is
based on the assumption that most MIME dispatchers will be
upgraded or built to support this +xml thingie. On the other hand
the RFC is very opposed to other, more general ways like for
example A.5 or A.7 (section of the appendix A), while these
approaches would require about the same level of support in MIME
dispatchers as the +xml suffix.

I'd be OK either with application/xml for SOAP or with something
like A.5(A.7) in a new release of MIME spec RFCs.

Best regards

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/


P.S: 21st century started on Sep 11, 2001



On Tue, 18 Sep 2001, christopher ferris wrote:

 > Jacek,
 >
 > application/soap+xml is XML from the viewpoint
 > of MIME content types as per 3023. Of course, there may
 > be a catch-up period before all MIME parsers
 > recognize this. That shouldn't stop this
 > from moving forward as 3023 *is* a standards track RFC.
 >
 > I do think though that the primary issue isn't so much
 > the media subtype, but the primary media type. I firmly
 > support application/* and oppose use of text/xml. If
 > it is determined that we won't go down the soap+xml
 > subtype, then it should be application/xml not text/xml.
 >
 > Cheers,
 >
 > Chris
 >
 > Jacek Kopecky wrote:
 > >
 > > Hello all. 8-)
 > >
 > > I'd like to voice my +1 on application/xml and on warning against
 > > the path of application/soap_for_book_buying_and_video_buying+xml.
 > >
 > > More specific identification of type than application/xml is done
 > > by the XML document's namespace.
 > >
 > > If an application needs to dispatch before parsing the document,
 > > that's what different endpoint URIs are for.
 > >
 > > If the application is given a URL, for example
 > > "http://foo.com/application", it should be allowed to get all
 > > messages for "http://foo.com/application/**" as well and then it
 > > can dispatch by this URL.
 > >
 > > What I don't like about application/soap+xml is that (AFAIK)
 > > soap+xml is not xml (from the viewpoint of MIME content types) so
 > > in case this subtype is not known the data won't even be treated
 > > as XML.
 > >
 > >                             Jacek Kopecky
 > >
 > >                             Idoox
 > >                             http://www.idoox.com/
 > >
 > > P.S: 21st century started on Sep 11, 2001
 > >
 > > On Mon, 17 Sep 2001, John J. Barton wrote:
 > >
 > >  > With all respect to the authors of RFC 3023 (XML Media Types),
 > >  > binding behavior to representations of Web resources is not
 > >  > at good engineering direction for Web technologies[1]
 > >  > A SOAP message is text: it can be read with text tools and
 > >  > it is encoded as XML so XML parsers can study it and parse
 > >  > further information without hints.  There should not be a
 > >  > different media type for XML sent to an "application"
 > >  > verses one sent to a "browser" (which is just another
 > >  > application).  The server should not assume the use of
 > >  > the media representation.
 > >  >
 > >  > Therefore application/xml is not necessary.  I suppose it
 > >  > may be to late to turn back from that.  But let us not go
 > >  > further down the path to application/soap+xml,
 > >  > application/soap_for_ecommerce+xml,
 > >  > application/soap_for_book_buying+xml
 > >  > application/soap_for_book_buying_and video_buying+xml, etc.
 > >  > Content-type should describe the media type, not its use,
 > >  > or provide other information that is elsewhere.
 > >  >
 > >  > [1] Roy Fielding, "Architectural Styles and the Design of
 > >  > Network-based Software Architectures",
 > >  > http://www.ebuilt.com/fielding/pubs/fielding_dissertation_2up.pdf
 > >  >
 > >  > John.
 > >  >
 >
Received on Tuesday, 18 September 2001 12:54:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT