RE: Final Proposal for Issue 41

Hi Henrik,

I guess I'd be more relaxed about what we write into the spec. than about
how we state that Issue 41 has been resolved.

The piece I in Amr's proposal that I had most difficulty was the notion of
placing the responsibility for sorting this out on the application
developer. Felt a bit like washing our hands of the problem and saying we'd
done a good job, rather than saying, actually we haven't addressed this one
entirely, but we that there is scope for it to be addressed as an extension.

However, that does leave the dangling question of who does take on the
responsibility to define such a standardised extension? Certainly we
(XMLP-WG) have no current charter to do so. A few *clearly experimental*
extensions to explore the space in the interim would be ok. But at some
stage I think we would want to synthesise a single recommendation.

regards

Stuart


> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 12 March 2002 19:49
> To: Williams, Stuart; amr.f.yassin@philips.com
> Cc: xml-dist-app@w3.org
> Subject: RE: Final Proposal for Issue 41
> 
> 
> 
> Stuart,
> 
> FWIW, I don't have anything particularly against the amended formulation
> but I am wondering whether we are not already covered with the current
> spec. In several places we state that routing, message exchange
> patterns, etc. are features and as such we expect that they may be
> defined although it is out of scope for us to say how.
> 
> Btw, I agree that not having a standardized mechanism would be bad but I
> don't think we should say anything about when and how that might happen
> in the spec. Hopefully the spec will stay around for a long time!
> 
> Henrik
> 
> -----Original Message-----
> From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com] 
> Sent: Tuesday, March 12, 2002 03:46
> To: 'amr.f.yassin@philips.com'
> Cc: xml-dist-app@w3.org
> Subject: RE: Final Proposal for Issue 41
> 
> 
> Amr,
> 
> A couple of things... firstly the issue is about the there being no
> provision *within a SOAP envelope* to identify the target "program,
> service or object " so... I think the first sentence need to 
> be extended
> with "...within a SOAP Envelope." I think this is true of the ultimate
> recipient, but we do provide a means (within the envelope) to identify
> the role that SOAP header blocks are targetted to.
> 
> I am also uncomfortable that we place the responsibility on 
> application
> designers to effectively develop routing extensions for themselves. I
> think applications designers will be looking to us for a set of
> standardised SOAP extensions - otherwise we head for an 
> interoperability
> nightmare.So, I believe that responsibility comes back to this group
> (probably under some future charter) to provide a single standardised
> extension for the expression of message paths and the 
> identification of
> ultimate recipients.
> 
> <amended proposal>
> Add the following text to (Part 1 Section 7: Use of URI in SOAP): 
> 
> SOAP 1.2 does not provide any normative means to carry the identity of
> the ultimate recipient within a SOAP envelope. SOAP 1.2 does provide a
> means to identify the roles that a SOAP header block is targetted to.
> 
> SOAP 1.2 does not provide any normative means for the expression of a
> message path with a SOAP envelope. However, it does provide means for
> the development of SOAP extensions that provides for such expression
> within SOAP header blocks. [Work to define a message routing extension
> for SOAP may be the subject of future WG activity within the W3C.]
> </amended proposal>
> 
> For the most part we have not actually addressed the issue, 
> and I think
> we should say so rather than cast it as a responsibility on the
> app.developer. I've put the lats sentence in [] to make it optional,
> since it sets some expectation - which may be inappropriate given that
> they lay outside our current charter.
> 
> Regards
> 
> Stuart
>

Received on Wednesday, 13 March 2002 06:46:25 UTC