Re: Issue 6413 - just thinking

+1

I'd really like to hear the usecases for fragment support being used 
outside of Transfer. 

Yves - you can do what you want today - without a frag spec (or RT) and 
its generic.  The way you do it is to have the service return a set of 
EPRs back to the client.  Then the client can choose which EPR/frag it 
wants to use. The key here is that the service decides which bits of the 
resource can be exposed as individual resources/EPRs not the client.  This 
is really no different than what we see in other places.  Allowing the 
client to "make up" its own fragment identifier portion of an EPR (as 
you're proposing) would be akin to the client telling the service that it 
_must_ expose a resource with that particular EPR and that's not 
appropriate.  By keeping the right to create EPRs with the service, it 
would then also allow the service the ability to control the granularity 
of those resources or even _if_ it wants to allow portion of a resource to 
be treated as individual resources.

Ultimately Transfer is about an EPR pointing to _a_ resource.  Whether or 
not there might be sub-resources present isn't relevant. For whatever 
reason the service gave a particular EPR to the client and that's the EPR 
it needs to use.  If the service wants to expose sub-resources as 
individual EPRs then its free to do so but it need to provide some 
mechanism by which the client can get those EPRs.  Perhaps some method 
like:  generateEPR( fragment ) or perhaps sprinkle EPRs in the resource's 
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 
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  :-)

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Katy Warr <katy_warr@uk.ibm.com> 
05/06/2009 05:51 AM

To
Yves Lafon <ylafon@w3.org>
cc
Doug Davis/Raleigh/IBM@IBMUS, Geoff Bullen <Geoff.Bullen@microsoft.com>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
Re: Issue 6413 - just thinking







Yves 

I guess that by 'more general' you mean that a separate fragment spec 
would be re-usable outside the context of WS-Transfer?   In theory, I 
could imagine this might be a possibility but, in practice, I can't think 
of a real example.  I'm concerned that we'd create an extra specification 
that would never be used outside the context of WS-T.  Worse still, a high 
proportion of use cases will require both specs so ultimately they will be 
read as a single specification. 

That said, I fully understand the argument to keep the WS-T specification 
'pure' for scenarios that don't implement fragments.  By placing the 
fragment text in the appendix (rather than the main body), we'll do 
exactly that.   

Best regards 
Katy 


From: 
Yves Lafon <ylafon@w3.org> 
To: 
Doug Davis <dug@us.ibm.com> 
Cc: 
Geoff Bullen <Geoff.Bullen@microsoft.com>, 
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>, 
public-ws-resource-access-request@w3.org 
Date: 
06/05/2009 08:52 
Subject: 
Re: Issue 6413 - just thinking




On Tue, 5 May 2009, Doug Davis wrote:

> Geoff,
>  Allow me to turn it around for a sec... if the general premise of
> "strongly encouraging" is agreed to, and people do not "want a
> proliferation of fragment specs", then an obvious question (to me 
anyway)
> is: what's so bad about having it in Transfer?  I've heard (and 
understand

If the fragment definition is in Transfer, then it is quite likely 
somebody else will define another "fragment spec" be it more general, or 
attached to another spec. That's why having a standalone document for 
fragment definition makes far more sense, it can be referred from 
Transfer, but also from other specs that don't want to reuse Transfer.

As I said during the call, fragments definition are more linked to the
addressing or resources than the action on them (and for the record, 
having the action distinct form the URI of the service is, well, 
suboptimal. At least transfer allows action to be a set of properties, but 

I digress ;) ).

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

        ~~Yves









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU