Re: soap:body and media types (fwd)

Hi Noah,

On Mon, Apr 25, 2005 at 04:09:03PM -0400, noah_mendelsohn@us.ibm.com wrote:
> 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.

Fair enough.  I've never really bought the whole Infoset thing, but I
respect that SOAP is defined in those terms.

>  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.

Depends what you mean by "octet stream", I guess.  I just think of it
as the message payload, and, at least by my definition of "message",
messages are still exchanged in-process, including in your example.  Of
course, the information normally conveyed by a media type need not be
conveyed explicitly in that message, but may instead be established out
of band.  For example, imagine that we copy RFC 2616, except we mandate
that the Content-Type header must always be text/html.  If we then
register port 55555 with IANA, and associate it with this new spec, then
we know that all messages on port 55555 are declaring that their
payloads have text/html semantics.

So the media type needn't be a part of every exchange.  But in the
absence of any out of band information, I think it's needed, otherwise
you have a loss of self-description and resulting ambiguity.  I'm not
sure about the intricacies of EIIs, but if you mean effectively an
Infoset with a single EII, then I could well imagine exchange
scenarios involving no out of band information and therefore the need
a data semantic indication mechanism like a media type.

>  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.

SOAP "has" protocol independence in that it supports multiple underlying
protocols, and I'm very supportive of that.  FWIW, I'm just not
supportive of the kind of protocol independence where developers are
isolated from the semantics of underlying application protocols;
something SOAP doesn't, and shouldn't, say much about.

Hmm, I'm not sure that was relevant to my point, but oh well.

> 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.

Ok.

> 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. 

As above, I think there should be an obligation to use a media type when
there's no out of band mechanism to accomplish the task.  To not do so
would make it impossible to distinguish, for example, between a SOAP
message carrying an XHTML document, and one carrying a shortform XSLT
stylesheet, since they'd be bytewise identical;

http://www.markbaker.ca/Talks/2004-media-types-and-compdocs/slide4-0.html

> 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.

I think both are important.  But even if the answer to #1 was "No", it
still seems to me that XML SOAP messages transferred via application
protocols which provide no out of band indication of the semantics of
the data (e.g. SMTP, HTTP, but not FTP), should use a media type.

Hmm, I see I repeated my main point a couple of times.  Sorry, that's
what I get for writing a message over several sessions! 8-/

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

Received on Wednesday, 27 April 2005 19:34:49 UTC