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

Re: Issue 6413 - just thinking

From: ashok malhotra <ashok.malhotra@oracle.com>
Date: Wed, 06 May 2009 05:31:28 -0700
Message-ID: <4A018320.9020603@oracle.com>
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
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

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