W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2003

PASWA, Include and Protocol Bindings

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 2 May 2003 14:46:21 -0400
To: xml-dist-app@w3.org
Message-ID: <OFFDAA928A.F6D6BB99-ON85256D1A.00662CE9@lotus.com>

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

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


[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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:23 UTC