Re: text/xml for SOAP is incorrect

Anywhere where you route SOAP through underlying protocol
intermediaries.

For example, a corporation that forces all HTTP through a firewall.
Or an ISP that does transparent redirection to a HTTP proxy. or a
content delivery network (the business that I happen to be in right
now) which provides services at the 'edge' of the network. All of
these scenarios have the potential to transcode documents, and mime
type is the preferred way to select the candidates for
transformation.

We decided to use port 80 to allow reuse of existing infrastructure;
IMHO, we should try to interact well with that infrastructure.

Cheers,



On Thu, Sep 20, 2001 at 11:42:47AM +0200, 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
>  >
>  >
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 20 September 2001 10:50:00 UTC