RE: Issue 6413 - just thinking

> 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.

Fragment access provides a generic framework for accessing fragments of a resource, but the client still has to have intimate knowledge of the way in which fragments are supported within the particular resource it is talking to.  How does the client gain such knowledge?  There is no method called generateFragments that will return fragment definitions, so that the client can use XPath to access them.

If it is OK for the client to know the details of how to setup an appropriate XPath query, why is it not OK for the client to know how to generate, say, a URI that represents the fragment (e.g. http:/.../myresource?section=a&subsection=b)

As a side note, how did the client get the top level EPR in the first place?  Could you not get the fragment EPRs the same way?  What is actually the difference between a "resource" EPR and a "fragment" EPR?

Just trying seeking a clear understanding of the real issues here.
--Geoff

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, May 06, 2009 7:46 AM
To: Katy Warr
Cc: Geoff Bullen; public-ws-resource-access@w3.org; Yves Lafon
Subject: 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