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

Re: Modelling the sender as a node that does processing & Handling comments in SOAP

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 10 Apr 2003 12:13:20 -0400
To: "Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
Cc: xml-dist-app@w3.org
Message-ID: <OF912A9FBD.A6A27E48-ON85256D04.0059793C@lotus.com>

I think this has been overtaken by our decision yesterday, which is 
largely consistent with the direction suggested in your note.  Yes, I was 
concerned that we hadn't explicitly considered whether initial senders 
need send comments (because many implementations don't in fact like to 
store a complete DOM, but to use some more SOAP-optimized internal 
representations of wire formats.)  That said, I think we've made a 
reasonable decision, which is to clarify at least in our minutes that 
senders must indeed preserve comments, except insofar as changes are 
allowed by the Infoset relay rules.

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







"Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr>
Sent by: xml-dist-app-request@w3.org
04/09/03 03:44 AM

 
        To:     noah_mendelsohn@us.ibm.com
        cc:     xml-dist-app@w3.org
        Subject:        Modelling the sender as a node that does processing &  Handling comments 
in SOAP



Noah,

My assumption was that the initial sender would always do what is 
appropriate with commments, i.e. send them, and that the problem would 
only occur at receivers, i.e. intermediaries, which might not transmit 
comments. The feature/header block was to prevent intermediaries from 
discarding comments. Are you saying it might be too late, because 
comments may have been discarded by the XML parser already, before the 
processing model kicks in?

Re. modelling "the sender [...] as a node that does processing", the 
recent "Infoset Addendum to SwA" proposal[1] goes some way towards that 
direction, with the DoInclude header block.

Jean-Jacques.

[1] http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html

noah_mendelsohn@us.ibm.com wrote:

> Jean-Jacques Moreau writes:
> 
> 
>>>I prefer B2 ("MAY transmit comments"). 
>>>Requiring all comments to be transmitted 
>>>could then be achieved via a feature/header block.
> 
> 
> I'm not so sure.  Our processing model requires that headers and 
> mustUnderstand be checked by receivers, not senders.  Certainly we can 
> define a binding-level feature that happens to depend on headers in the 
> outbound message, but I think that's a bit subtle.  Any mustUnderstand 
> checking will only be done at the receivers, which is in general too 
late 
> I think.
> 
> So, I think we either have to live with "MAY" transmit (or SHOULD or 
> something similar implying flexibility), or we stick with our current 
> model which is:  the bindings transmit the Infoset.  I think it is 
> coherent to have a binding level feature to indicate whether comments 
are 
> transmitted, but its enforcement cannot be mU on a header.  If we have a 

> binding-level feature, then I think we have to document that, and decide 

> how the HTTP binding supports it.
> 
> By the way, I've always wondered whether we shouldn't model the sender 
as 
> well as the receiver as a node that does processing...this would indeed 
> allow us to use mU headers to trigger this behaviour.  I think we're too 

> late in the design process for that now.
> 
> I'm still not 100% sure what I think is best regarding comment handling. 
I 
> can see use cases both ways. 
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
Received on Thursday, 10 April 2003 12:20:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:14 GMT