W3C home > Mailing lists > Public > public-ws-resource-access@w3.org > May 2009

Re: Issue 6413 - just thinking

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 6 May 2009 15:57:52 -0400 (EDT)
To: Doug Davis <dug@us.ibm.com>
cc: Katy Warr <katy_warr@uk.ibm.com>, Geoff Bullen <Geoff.Bullen@microsoft.com>, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Message-ID: <alpine.DEB.1.10.0905061550580.5004@wnl.j3.bet>
On Wed, 6 May 2009, Doug Davis wrote:

> XML at each sub-resource location.  But, in the end you still end up with
> a single EPR to a single resource and you're asking the application
> (Transfer in this case) to act on it.  From an Addressing perspective

Well Transfer is just qualifying the exchange, so basically your point is 
that it's the application definition that defines the meaning of the 

> that's as fine grained as the client can get.  At that point we're within
> the Transfer application and _if_ people want to ask for finer grained
> manipulation that's where the Transfer fragment stuff comes into play.
> We're no longer at the infrastructural/WSAddressing layer - we're within
> the application.  This is why we do not view this as an Addressing issue
> and also why the fragment stuff should be in the SOAP Body and not a
> Header.  We believe that the application data belongs in the Body but
> that's probably a different topic  :-)

Ok, so the logic is different, but if we take this approach, the logical 
way of defining fragment is along the applicative spec that will consume 
this definition. In this case, RT, as T doesn't define the application in 
RT. So it seems that the best bet is to put this fragment definition (as 
it won't be a generic one) back in RT.

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Wednesday, 6 May 2009 19:58:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:49 UTC