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: Thu, 20 Sep 2001 11:42:47 +0200 (CEST)
To: Mark Nottingham <mnot@mnot.net>
cc: <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0109201136510.29512-100000@mail.idoox.com>
 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.
 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


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:43:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC