- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 20 Sep 2001 10:45:14 -0700
- To: "John J. Barton" <John_Barton@hpl.hp.com>
- Cc: Mark Baker <distobj@acm.org>, Andrew Layman <andrewl@microsoft.com>, xml-dist-app@w3.org, dave@scripting.com
On Thu, Sep 20, 2001 at 10:29:15AM -0700, John J. Barton wrote: > At 03:10 PM 9/19/2001 -0700, 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. > > Is application/xml defined as a media type that is XHTML and can be > transformed by an intermediary? If so, then no SOAP application > should send application/xml. If not, then any intermediary that > pretends that "application/xml means XHTML" will just be > misdesigned. > > It is my understanding that application/xml does not imply XHTML > and transformable. Developers of intermediaries should band > together to develop a clear, unambiguous, and efficient header for > transformable XML content. In my opinion they will not be able to > use application/xml for this whether or not SOAP uses it for its > media type. Anything sent by HTTP is transformable, unless it has a 'no-transform' Cache-Control header associated. Additionally, it is an unfortunate truth that intermediaries may not honor no-transform, because the access provicer's policy is that the transformation is not optional. application/xml implies that it may be XHTML. -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 20 September 2001 13:45:19 UTC