Re: text/xml for SOAP is incorrect

I have to ammend what I just wrote:

IMHO application/soap+xml is better than application/soap
>>>without specifying in any MIME way that it's XML<<<, like the
ways discussed in RFC 3023 appendix A sections 5, 7, 8 or 9.

I think I'd prefer something more general for MIME, not an
XML-specific addition to how content-types are formed.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Thu, 20 Sep 2001, Jacek Kopecky wrote:

 >  Mark,
 >  I see what you mean, but cannot see a viable scenario where both
 > XHTML and SOAP documents would go through a single-endpoint
 > intermediary that changes XHTML.
 >  My preference is application/xml, but if you show me a scenario
 > that is obviously not a case of bad design, and which does need
 > something else than application/xml, I can change my favourite.
 > 8-)
 >  Anyway, IMHO application/soap+xml is better than
 > application/soap because the former _can_ support some genericity
 > even though via XML-specific means (RFC 3023).
 >  Best regards,
 >
 >                             Jacek Kopecky
 >
 >                             Idoox
 >                             http://www.idoox.com/
 >
 >
 >
 > On Wed, 19 Sep 2001, Mark Nottingham wrote:
 >
 >  >
 >  > So, let's imagine an intermediary that modifies XHTML in-flight (not
 >  > pleasant, I know, but bear with me).
 >  >
 >  > If SOAP and XHTML share application/xml, the intermediary can't use
 >  > the content-type to find XHTML messages for processing, which it can
 >  > scan for very efficienty. Instead, to behave properly, it has to look
 >  > for application/xml, and then parse the XML (perhaps with SAX, so
 >  > that they can stream) to figure out what the root namespace is.
 >  >
 >  > The cost of doing this is high, considering that someone writing
 >  > XHTML modification code may only be vaguely aware or caring of other
 >  > XML applications may cross its doorstep. More to the point, such an
 >  > application that does operate correctly (by deriving the namespace)
 >  > needs to buffer and parse *every* message with content-type:
 >  > application/xml until it determines the namespace in use.
 >  >
 >  > Other configurations (a SOAP intermediary interposed on a HTTP
 >  > intermediary, for instance) have similar behaviours; all XHTML
 >  > messages will be buffered, to make sure that they're not SOAP. The
 >  > more XML formats that use application/XML, the more of a bottleneck
 >  > that this has the potential of becoming.
 >  >
 >  > This may seem trivial, but intermediaries are some of the most
 >  > performance-sensitive devices out there. Imposing a high processing
 >  > cost on a large chunk of traffic in order to identify a small portion
 >  > of it isn't appealing to intermediary vendors. For better or worse,
 >  > they have a history of creative work-arounds to specified behaviours
 >  > that have large performance penalties.
 >  >
 >  > Most of the larger companies represented in the WG have HTTP
 >  > intermediary products of some kind, and some have direct interest in
 >  > intermediary processing models; I'd encourage discussing this issue
 >  > with those teams.
 >  >
 >  > Cheers,
 >  >
 >  >
 >  >
 >  > On Wed, Sep 19, 2001 at 05:23:21PM -0400, Mark Baker wrote:
 >  > > > I'd reiterate that other W3C XML-based formats have chosen to define
 >  > > > their own content-type. Perhaps we should explore the reasoning of
 >  > > > those groups (SVG and SMIL, to start with).
 >  > >
 >  > > FWIW, XHTML 1.0 was held up for quite a while because of two issues;
 >  > > one, the "three namespaces vs. one" debate, and the other, that XHTML
 >  > > should not be sent as text/xml or application/xml[1].  The concern
 >  > > expressed by Sun and others was that because XML namespaces weren't well
 >  > > deployed (though that was in late '99), "img", "h1", and other well known
 >  > > HTML elements (or perhaps all of HTML) would somehow find special status
 >  > > in a "root namespace" such that they would be usable as-is in other XML
 >  > > formats that didn't use namespaces.
 >  > >
 >  > >  [1] http://www.w3.org/TR/1999/PR-xhtml1-19990824/#media
 >  > >
 >  > > MB
 >  >
 >  >
 >
 >

Received on Thursday, 20 September 2001 05:48:25 UTC