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

RE: Issue 6413 - just thinking

From: Doug Davis <dug@us.ibm.com>
Date: Wed, 6 May 2009 21:01:08 -0400
To: public-ws-resource-access@w3.org
Message-ID: <OFF4298030.EA1D49F6-ON852575AF.0004F5FC-852575AF.00059AEB@us.ibm.com>
ROFLMAO -  I don't think so.
Transfer is about dealing with the XML representation of a resource - 
Eventing is not.  For WS-E the XML on the wire is just there as a 
serialization thingy.  There are some soap bindings that would never have 
a Subscribe() appear as XML at all (e.g. a java binding - which I've 
used).  However, the Transfer operations would still result in XML being 
passed around.  We're talking about two very different types of services 
here.  Since the application (in the transfer case) is dealing with XML, 
the optimization of narrowing down that XML (which could be large) into a 
smaller piece makes sense.  I'm failing to see how this could possibly 
apply (in the same way) to Eventing.

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 08:45 PM

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






Gil,
 
> Why wouldn't these sub-event sources have their own EPRs?
 
That is a really good question!  And if sub-event sources should have 
their own EPRs, then it also makes sense that sub-transfer resources 
should also have their own EPRs, for the same reason.  However, Doug , on 
another thread (see 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0052.html
) has just said:
 
Once the client has an EPR to a resource, it?s just a resource.  The 
question is, how do you get more granularity if the service won't give you 
an EPR to something lower down?  ta da... fragments  ;-)
 
So, based on Doug?s comment above, Doug?s answer to your question (?Why 
wouldn?t these sub-event sources have their own EPRs?) is that the 
EPR/Service (M) ?won?t give you an EPR to something lower down?, so 
therefore you need fragments.
 
The point that you make Gil, is that the Eventing use case is not valid if 
fragment access itself is not valid. 
But, if fragment access is valid, as Doug contends, then the Eventing use 
case is also valid.
If the Eventing use case is valid, then the fragment access spec must be 
separated from the Transfer spec, since the fragment access spec has 
generic use cases.
 
--Geoff
 
 
From: Gilbert Pilz [mailto:gilbert.pilz@oracle.com] 
Sent: Wednesday, May 06, 2009 3:26 PM
To: Geoff Bullen
Cc: ashok.malhotra@oracle.com; Katy Warr; Yves Lafon; Doug Davis; 
public-ws-resource-access@w3.org
Subject: Re: Issue 6413 - just thinking
 
Geoff,

I'm missing something here. Why wouldn't these sub-event sources have 
their own EPRs?

- gp

Geoff Bullen wrote: 
Events cannot be broken into fragments.
    
Possibly not, but event sources certainly can be.
 
In the same way that one might have an EPR (M) and want to "Transfer/Put" 
some new content into a fragment (hardware) associated with that EPR, one 
might also have the same EPR (M) and want to only be sent events generated 
by a particular fragment (hardware) of the EPR.
 
 
-----Original Message-----
From: ashok malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Wednesday, May 06, 2009 2:14 PM
To: Geoff Bullen
Cc: Katy Warr; Yves Lafon; Doug Davis; public-ws-resource-access@w3.org
Subject: Re: Issue 6413 - just thinking
 
I'm sorry Geoff, your analogy from events to a machine with several 
parts is not convincing.
Events cannot be broken into fragments.
All the best, Ashok
 
 
Geoff Bullen wrote:
  
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/
 
 
 
 
 
    
 
 
  
Received on Thursday, 7 May 2009 01:01:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:17:59 GMT