- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 2 May 2003 14:46:21 -0400
- To: xml-dist-app@w3.org
Now that the floor is open for discussion of PASWA [1]... In section 4, PASWA proposes the use of a so-called xbinc:Include element [2]. This essentially replaces the literal character representation of a (logically) binary object with an element in the spirit of XInclude [3]. My comment here is neither to endorse nor to discourage consideration of such a mechanism. Rather, I would like to suggest that the proposal needs to be better related to the mechanisms of SOAP 1.2. Specifically, SOAP refers to an envelope infoset, and gives responsibility to a Protocol Binding Specification for determining how the data will actually look "on the wire". I think what's intended by PASWA might better be layered in the following manner: * The envelope infoset invariably represents (what we have previously called) attachments as character children in the infoset. * (here's the change) Protocol bindings MAY use a wire representation in which (a) the envelope infoset transmitted on the wire has such element children replaced with an <xbinc:Include> element and (b) that element MUST refer to a URI that the binding warrants will resolve to a binary stream, which has as its base64 canonical form the original characters. Of course, there are other ways to present the architecture, but I think we need to always refer to the normative SOAP model, which deals with only one infoset. There is nothing in the SOAP architecture that says: "take the received infoset, rewrite it, and then rerun the SOAP processing model." One could claim that the xbinc:DoInclude element [4] carries that rather elaborate semantic, but it seems to be a big, big extension to the SOAP processing model. It wouldn't be surprising that it would raise all sorts of edge cases for intermediaries, signatures and the like down the road. Certainly it would need to be specified very carefully and formally. It seems to me that our precedent in SOAP is: there is one application view of the infoset. I really don't think I want applications or the SOAP processing model itself to see the xbinc:Include elements. Optimizations of representions for efficient transmission belong in the bindings. Note that the doInclude element can be retained, if you like, as there's nothing to prevent a binding from being aware of the presence of headers (though it doesn't use the processing model on them.) On the other hand, I'm not sure that keeping it is necessary. I think we should at least explore that layering of the PASWA proposal. Thanks! Noah [1] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html [2] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html#_Toc36994428 [3] http://www.w3.org/TR/xinclude/ [4] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html#_Toc36994431 ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------
Received on Friday, 2 May 2003 14:55:03 UTC