Re: PASWA, Include and Protocol Bindings

Hi Noah.  I certainly agree with the idea that the all issues
regarding the spatial representation of the message belong
outside of the SOAP proper. (I think we can have "packaging"
separate from "transfer" to increase reuse).

However, there is one important issue in your note below that
I'd like to understand better.  As I read the infoset docs, the
bit representation of components of the infoset are *not* defined.
That is, infoset as I understand it is silent on binary vs base64
vs plain text or whatever.  So Infoset is about the data structure
not the data representation.  Is the correct?

If this is true, then does the SOAP envelop infoset add restrictions
that mandate the data representation?

Thanks,
John.

At 02:46 PM 5/2/2003 -0400, noah_mendelsohn@us.ibm.com wrote:

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

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Monday, 5 May 2003 16:50:03 UTC