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.