Re: soap:body and media types (fwd)

This is in response to a note that Mark Baker sent to xmlpComments [1].

Mark Baker writes:

> Something Noah Mendelsohn said at the technical
> plenary week about SOAP & media types, made me
> realize that the SOAP envelope currently has a
> problem; that it cannot communicate the media type
> of the document encapsulated within the SOAP body.

There are some subtleties here, I think, some of which were obliquely
touched upon at the TAG F2F in Boston.   As far as I know, media types
apply to octet streams.  SOAP envelopes are not in general octet streams,
but are instead Infosets. The content  of the body is an Element Info
Item.  Consider, for example, an implementation that uses SOAP for
communication between processes on a single machine.  It would be quite
reasonable to have a SOAP implementation that communicates using DOM or
SAX, without ever serializing to an octet stream.  It is true that SOAP
envelopes as serialized by the normal HTTP binding are octet streams,
typically of media type application/soap+xml.  As I recall you are not a
particular fan of protocol independence, Mark, but SOAP has it, and SOAP
envelopes are Infosets.

Thus, I think there are at least two questions implicitly raised by your
note:

1. Is it appropriate to apply a media type to something other than an
octet stream,  e.g. to an element information item?    I have considered
raising this as  a TAG issue, but it seems to me that it is not in any
case appropriately a decision for the XMLP WG.

2. I suspect the answer at the moment is "no", but let's assume for sake
of discussion it's actually "yes":  then we can ask whether the subtrees
carried within SOAP bodies in particular should be media typed?  Note
that, in part due to limitations of XML itself, these are not in general
XML documents.  They cannot have their own XML declarations, internal
subsets, etc.  They are XML fragments, or more specifically element info
items.  Furthermore, it's not clear to me that there is an obligation to
carry the media type even if there were one.

I think the main architectural question is #1.  If that is resolved in
favor of typing infoset subtrees, then it would be straightforward to
define a SOAP header that would be usable to carry the type.

Noah

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2005Apr/0000.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

---------- Forwarded message ----------
Date: Sat, 2 Apr 2005 08:58:26 -0500
From: Mark Baker <distobj@acm.org>
To: xmlp-comments@w3.org
Subject: soap:body and media types
Resent-Date: Sat, 02 Apr 2005 13:58:40 +0000
Resent-From: xmlp-comments@w3.org


Something Noah Mendelsohn said at the technical plenary week about SOAP
& media types, made me realize that the SOAP envelope currently has a
problem; that it cannot communicate the media type of the document
encapsulated within the SOAP body.

It seems that "namespace dispatch" is implicit in SOAP, as the namespace
of the root element of the encapsulated document is used to infer the
intended semantics of that document.  However that approach has several
problems, including security, performance (both as a result of poor
layering), as well as expressibility; of being unable to, for example,
communicate the difference in semantics of an XHTML document and an XSLT
simplified stylesheet[1].

A fix would be to provide a standardized "Content-Type" header so one
could say;

   <env:Envelope xmlns="..."
     <env:Header>
       <foo:Content-Type
mustUnderstand="true">application/xhtml+xml</foo:Content-Type>
     </env:Header>
     <env:Body>
       <html xsl:version="1.0"
             xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
             xmlns="http://www.w3.org/TR/xhtml1/strict">
       ...

Of course, it would have to use a mandatory extension in the case where
it's being used to address the problem I described above, otherwise
receiving agents would be licensed to assume namespace dispatch.

And FWIW, I'm not actually proposing anything be done; I just wanted to
note this for the record.

Also FWIW, this issue is pretty similar to one facing the Compound
Document Formats WG, of which I'm a member.  I gave a presentation[2] to
them on this topic at our January f2f.

  [1] http://www.w3.org/TR/xslt#result-element-stylesheet
  [2]
http://www.markbaker.ca/Talks/2004-media-types-and-compdocs/slide1-0.html

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 25 April 2005 20:09:22 UTC