RE: Issue 6413 - just thinking

> 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 Wednesday, 6 May 2009 21:32:17 UTC