- 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>
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
fragment.
> 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.
~~Yves
Received on Wednesday, 6 May 2009 19:58:13 UTC