RE: Issue 6413 - just thinking

Geoff,
  what you're describing here is a new form of addressing and clearly 
outside the scope of WSRA.  If you honestly believe that a generic 
solution can (and should) be developed to solve both the Transfer Frag use 
case and the use case you describe below (without painful contortions) 
then I would suggest that you write up a proposal that MSFT will submit to 
the W3C. 

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.



Geoff Bullen <Geoff.Bullen@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
05/06/2009 04:52 PM

To
Katy Warr <katy_warr@uk.ibm.com>, Yves Lafon <ylafon@w3.org>
cc
Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" 
<public-ws-resource-access@w3.org>
Subject
RE: Issue 6413 - just thinking






Hi Katy,
 
> 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.
 
Many people appear to be saying that because they cannot think of a real 
example, therefore none exists, so therefore the WG should not be taking 
the fact that an example might exist into consideration.  While this 
?ostrich? thinking seems rather odd, especially when making such a 
fundamental decision concerning a specification, let?s look at a real 
example:
 
Consider filtering in Eventing (the same reasoning would also work for 
Enumeration). 
In the example, we have an endpoint that represents a machine (M).
We want to subscribe to events from M ? but not all of them.  How do we do 
that?
 
The basic filtering mechanism in Eventing supports an XPath filter that 
will allow subscribers to define a subset of the events from M, based on 
the content of the event.
 
Now consider that M has many sub-resources (fragments).  For example, it 
has an operating system, it has hardware ? which, in turn, is made up of a 
disk, a CPU, etc.  If M had a new filter type that composed with fragment 
access, subscribers would now be able to filter the events not only on the 
content of the event, but also on the sub-resource (fragment) that 
generated the event (i.e. only be sent events that were hardware related, 
for example).  This would be a very useful filter in many situations.
 
Basically anywhere there is a need to provide a filtering mechanism there 
is also a potential need to compose with fragment access.
 
> Worse still, a high proportion of use cases will require both specs so 
ultimately they will be read as a single specification.
 
Does this really mean ?? a high proportion of IBM use cases ???  The 
industry at large has many implementations of Transfer as it stands, and 
there are also many other specifications that reference Transfer, so there 
appears no real justification for saying that, in general, a high 
proportion of use cases require fragment support ? it just is not the 
case.
 
--Geoff
 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Katy Warr
Sent: Wednesday, May 06, 2009 2:52 AM
To: Yves Lafon
Cc: Doug Davis; Geoff Bullen; 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