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

Re: Issue 6413 - just thinking

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 6 May 2009 10:26:49 -0400 (EDT)
To: Katy Warr <katy_warr@uk.ibm.com>
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>
Message-ID: <alpine.DEB.1.10.0905061026020.13024@wnl.j3.bet>
On Wed, 6 May 2009, Katy Warr wrote:

> 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

Ok, so following the same logic, SOAP and WSDL should be in the same spec 
and namespace, almost nobody using WSDL is not using SOAP, so it would be 
a good match.
I think I am not sold to that idea ;)

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

Received on Wednesday, 6 May 2009 14:27:03 UTC

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