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.