RE: Issue 6413 - just thinking

Doug,

> but I'm willing to accept that you honestly believe that anything that even remotely looks the same should be moved into a new specification.

Fragment access is already in a separate spec, called RT.  We are not proposing that it be moved anywhere.  In this case is it IBM who is proposing that it move from being in a separate spec, to being in a spec combined with Transfer.  We have been discussing the motives and value in combining these specs together in order to seek consensus.

> So, prove to me that you're not being selective in this reasoning and are serious about this by opening a new issue that removes the Filter element from both Eventing and Enumeration and moves it into a new spec since I doubt anyone would disagree that there is clear duplication of function in that case.

Let's look at a filter example as see if there is a duplication of function.  Here is an Eventing filter example:
<wse:Filter Dialect="http://www.w3.org/TR/1999/REC-xpath-19991116" >
   XPath content
</wse:Filter>
The Eventing specification has a concept called a Filter, which filters events that should be sent to the subscriber.   The Filter element composes with the XPath definitions found at "http://www.w3.org/TR/1999/REC-xpath-19991116".  This is good, because the Eventing spec, due to this composition, does not have to define the contents of the Filter element, those contents are defined in the XPath spec.  This seems to be exactly what is also being done in the Format example below, only in the Format example the composition is with RT.  Again, the purpose of the composition is that the contents of the Format element do not need to be specified directly, the contents are defined in the RT spec.

The contents of both the XPath and RT specs are quite large and so it makes sense not to redefine them in every spec.  These two examples seem to be very similar is scope, value and purpose, so if composing with XPath is a good idea then similarly for RT.

Now it is true that both the Eventing and the Enumeration specs do contain a Filter element.  Separating out the actual Filter element itself (rather than the contents) into a new spec seems like an entirely different level of composition, and the pros and cons need to be weighed accordingly.  There seems to be no precedent for separating out a single element into a new specification, but there are many examples of reusing other specifications as the contents of elements.

> then I'll believe that this isn't a distraction

Doug, this mail thread was started based on the strong contention by you, Katy and Ashok that there were no uses cases for composing RT with anything other than Transfer.  This contention was used as a primary justification for merging the two specs together.  It is not a distraction to question this contention, the aim is to increase understanding and seek consensus.

Is there still a strong conviction in the WG that no use case exists for composing RT with anything else other that Transfer, or is the Format example below evidence of such a use case?

--Geoff


From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Friday, May 08, 2009 3:36 AM
To: public-ws-resource-access@w3.org
Subject: RE: Issue 6413 - just thinking


Geoff,
  I find this line of reasoning contorted :-)  but I'm willing to accept that you honestly believe that anything that even remotely looks the same should be moved into a new specification.  So, prove to me that you're not being selective in this reasoning and are serious about this by opening a new issue that removes the Filter element from both Eventing and Enumeration and moves it into a new spec since I doubt anyone would disagree that there is clear duplication of function in that case.  When that happens, and we resolve that issue by creating a new spec , then I'll believe that this isn't a distraction.

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>

05/07/2009 10:12 PM

To

Doug Davis/Raleigh/IBM@IBMUS, "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>

cc

Subject

RE: Issue 6413 - just thinking







Doug,
Thanks for the clarification email below.  It helps increase understanding of IBM's position with respect to fragment support.

Given that, perhaps it would be good for the WG to look at one more example of possibly "composing" RT with something other than Transfer.

There is an Eventing source (E) and when clients subscribe, they are sent very large events, say 1MB in size.  The Events that are sent contain lots of sub-sections (fragments), and most clients only want to look at one particular subsection or another.  So the implementer of E decides to compose with part of RT to allow the clients to subscribe in such a way that E will deliver only part of the entire XML event message.  A subscribe to E might look something like:

<subscribe>
  <NotifyTo> ... </NotifyTo>
  <delivery ...> ... </delivery>
  <format name=".../RT-FragmentTransfer-XPath">
      <wsrt:Expression>
            subsection[2]
      </wsrt:Expression>
  </format>
  ...
</subscribe>

The above subscribe would only send the specified fragment of the event back to the client each time an event was available.  I would be interested to hear feedback from the group on the viability of such an example.

--Geoff



From: public-ws-resource-access-request@w3.org [mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, May 06, 2009 6:32 PM
To: public-ws-resource-access@w3.org
Subject: RE: Issue 6413 - just thinking


I should probably clarify something and I'm not sure how we got off track.
Fragments do not identify a sub-resource in the same way an EPR or URI identify a resource.  Fragment support is about an optimization.  Its for saying "I don't want to send the entire XML so I'm going to give you a snippet of it and provide you some way to know where that snippet comes from in the bigger XML picture".  So, we've probably gotten people confused by being too loose with our wording.  It _is not_ a way to "identify" some new resource.  As I've said before, if you want that get a new EPR.  Its just a way to tell the _Transfer application_ that the full XML is too big so I want to deal with just a subset - nothing more. If we can remember this then I think we'll stop confusing it with some sort of Addressing thing - which it is not.  And in that light it should be clearer why trying to map this to something like Eventing doesn't really fit.  In the usecase that Geoff described he really does want to send the Subscribe to a sub-resource, and that should require obtaining a new EPR.  It doesn't make any sense to say "I want to send only a subset of a resource's XML doc" in the Eventing Subscribe operation - I have no idea what that means - no resource XML is being transferred during that operation.

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.
Doug Davis/Raleigh/IBM@IBMUS
Sent by: public-ws-resource-access-request@w3.org

05/06/2009 09:01 PM


To

public-ws-resource-access@w3.org

cc

Subject

RE: Issue 6413 - just thinking












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<mailto: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>
[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<mailto: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><mailto:ylafon@w3.org>

To:



Doug Davis <dug@us.ibm.com><mailto:dug@us.ibm.com>

Cc:



Geoff Bullen <Geoff.Bullen@microsoft.com><mailto:Geoff.Bullen@microsoft.com>,
"public-ws-resource-access@w3.org"<mailto:public-ws-resource-access@w3.org> <public-ws-resource-access@w3.org><mailto:public-ws-resource-access@w3.org>,
public-ws-resource-access-request@w3.org<mailto: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/