RE: [Bug 6724] Eventing: define resource representation

You've proven my point.  This looks a lot like Transfer.   Now you have to 
answer all of the same questions that Transfer does... how do I indicate 
which fields are read-only vs updatable?  Not everyone will allow you to 
modify everything (e.g. Filters might be harder than the NotifyTo).  Or 
what does it mean when a field is missing? Is it cleared or not touched? A 
missing Filter can be either.  And you now have to explain how people can 
get the other fields that people might choose to expose - like the # of 
messages sent or processed.  How does the client know these fields exist? 
Once we solve 7068 we solve it implicitly.  You're going through a lot of 
pains to avoid reuse for some claim of complexity.  Its worth noting that 
Mex reuses Transfer as well and it only talks about Get() but its very 
possible to use Update() and Delete() too. And yet people aren't confused 
by that.  I'm missing what's complex about this case.

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
07/27/2009 07:14 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: [Bug 6724] Eventing: define resource representation






 
New Proposal for 6724:
 
This proposal adds to the existing Eventing model, is not ambiguous and 
includes the semantics of the known elements being requested or returned. 
It also restricts the changes to apply only to the Transfer Get and Put 
equivalents in Doug?s proposal, rather than extend the change to include 
anything to do with delete and create.
 
There would be four new elements defined for GetStatus and Renew.  Each 
element would be optional, but the Subscription Manager would be expected 
to support them if messages contained these elements.
 
GetStatus would become an operation that returns the current status of the 
subscription, including current contents.
Renew would allow you to change / renew contents of the subscription.
 
 
4.2 Renew request message would become:
 
[Action]
  http://www.w3.org/2009/02/ws-evt/Renew
 
[Body]
  <wse:Renew ...>
    <wse:Expires>(xs:dateTime | xs:duration)</wse:Expires> ?
    <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
    <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
    <wse:Delivery ...> xs:any* </wse:Delivery> ?
    <wse:EndTo> endpoint-reference </wse:EndTo> ?
    xs:any*
  </wse:Renew>
 
4.2 Renew Response message would become:
 
[Action]
  http://www.w3.org/2009/02/ws-evt/RenewResponse
 
[Body]
  <wse:RenewResponse ...>
    <wse:Expires>(xs:dateTime | xs:duration)</wse:Expires> ?
    <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
    <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
    <wse:Delivery ...> xs:any* </wse:Delivery> ?
    <wse:EndTo> endpoint-reference </wse:EndTo> ?
    xs:any*
  </wse:RenewResponse>
 
 
4.3 GetStatus response message would become:
 
[Action]
  http://www.w3.org/2009/02/ws-evt/GetStatusResponse
 
[Body]
  <wse:GetStatusResponse ...>
    <wse:Expires>(xs:dateTime | xs:duration)</wse:Expires> ?
    <wse:Filter Dialect="xs:anyURI"? ...> xs:any* </wse:Filter> ?
    <wse:Format Name="xs:anyURI"? > xs:any* </wse:Format> ?
    <wse:Delivery ...> xs:any* </wse:Delivery> ?
    <wse:EndTo> endpoint-reference </wse:EndTo> ?
    xs:any*
  </wse:GetStatusResponse>
 
 
From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Thursday, July 23, 2009 2:44 PM
To: Geoff Bullen
Cc: public-ws-resource-access@w3.org
Subject: RE: [Bug 6724] Eventing: define resource representation
 

Its not just those two properties - its any property of a subscription. 
But if you want to extend Renew and GetStatus then offer up a proposal. 
IMO, it'll look a lot like we're duplicating Transfer.  I don't see the 
confusion you claim exists - the text I proposed is very short and clear. 
Duplicating Transfer itself.... that'll add confusion. 

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-notifications-request@w3.org 
07/23/2009 05:30 PM 


To
"bugzilla@wiggum.w3.org" <bugzilla@wiggum.w3.org>, 
"public-ws-resource-access-notifications@w3.org" 
<public-ws-resource-access-notifications@w3.org> 
cc

Subject
RE: [Bug 6724] Eventing: define resource representation
 








Doug,

As we see it, here are the pros and the cons associated with this 
proposal.

Pros
1) Being able to change the values of NotifyTo and Filter, which cannot 
currently be changed.

Cons:
1) Since users do not know which interface to use or why they would choose 
a particular one, then  it seems to be adding ambiguity to the spec.  Why 
would the WG add new text that makes things more ambiguous?

2) The proposal turns a subscription into a Transfer resource, and implies 
that all Transfer operations could potentially be used with it.  This is 
not true, since Create does not work with the proposed model.  Subscribe 
operations (the equivalent of the Create) go to the Event Source, not the 
Subscription Manager. This makes it very confusing for implementers.

3) No one has implemented this to see if it really is a good idea or works 
well.  Will enough WG members implement it or will it just slow down the 
standardization process?

We would like to propose that instead of creating a whole new model based 
on Transfer, we simply add the optional ability to change NotifyTo and 
Filter to the Renew operation which is already defined.  That way we can 
minimize changes, keep the current model intact, minimizes confusion and 
still get what IBM wants.

--Geoff

-----Original Message-----
From: public-ws-resource-access-notifications-request@w3.org 
[mailto:public-ws-resource-access-notifications-request@w3.org] On Behalf 
Of bugzilla@wiggum.w3.org
Sent: Tuesday, July 21, 2009 11:55 AM
To: public-ws-resource-access-notifications@w3.org
Subject: [Bug 6724] Eventing: define resource representation

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6724





--- Comment #4 from Doug Davis <dug@us.ibm.com>  2009-07-21 18:54:38 ---
Minor tweak to the proposal (new text in ***)

Appendix B: Subscription Manager Resource Model

A Subscription Manager can choose to allow for retrieval and update of the
Expires time of a subscription through the use of the GetStatus and Renew
operations.  If it wishes it MAY also choose to expose the Subscription
Manager itself as a resource that can be accessed using resource access
specifications such as WS-Transfer *** - thus allowing access to the other
properties of the Subscription*** .  This specification places no
requirements on implementations with respect to which operations (if any)
that it supports.  Nor does this specification require that
implementations support updates to all properties of the resource.
However, if the Subscription Manager chooses to expose the Subscription
Manager as a resource then it MUST support the wse:Subscription schema
defined by this specification.  The outline for a Subscription Manager
resource is:
...


--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.