- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 06 May 2009 05:31:28 -0700
- To: Yves Lafon <ylafon@w3.org>
- CC: Doug Davis <dug@us.ibm.com>, 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
Yves: Just wondering. Are you thinking of the fragment spec as similar to the frag-id in URI's? That is quite different. I don't think the fragment spec we are thinking of will be reusable in other specs. If people disagree, I would like to see an example of where and how the fragment spec from from WS-RA would be reused. All the best, Ashok Yves Lafon wrote: > 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 ;) ). >
Received on Wednesday, 6 May 2009 12:37:02 UTC