[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia]=?utf-8?B?UkU6IFt3c3JwLXdzaWFdW0kjMTA2XSBQcm9wb3NlZCByZXNvbHV0?==?utf-8?B?aW9uOiBVbmlxdWVuZXNzIG9mIEVudGl0eSBIYW5kbGVz?=
Rich, I understand your point of view. You wish not to differentiate between the relationship and the process that created it. The way I see it is that in the spec today because entity management and markup receive a "registrationHandle" then it _seems_ that registration is mandatory, even though it is not. I think the important concept is the relationship between Producer and Consumer and not the process (registration) that may or may not be needed to create that relationship. What the entity management and markup interfaces need is a handle to the relationship and not to the process that created it. While this is tinkering with details, I have often found that clearness in the API generates a better understanding of it. A conceptual model where an interface needs a handle to the process implies that the process is necessary (which is false), while a model where an interface needs a handle to an object (relationship) implies that the relationship is necessary (which is true), even if that relationship can be a generic relationship (like a null relationship or a pre-defined string defining a generic relationship). Gil -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Mon, October 28, 2002 20:45 To: wsrp-wsia@lists.oasis-open.org Subject: RE: [wsrp-wsia][I#106] Proposed resolution: Uniqueness of Entity Handles I think I see our disconnect. My understanding is that for this handle to have _any_ value, a relationship was initiated through either an in-band or out-of- band process. We call that process registration in either case and therefore I find minimal value in renaming the handle. Will there be services offered where this handle is always null? I think so, basically this is a class of services offered for the purpose of gaining mindshare with the End-User. Any little thing that lowers the barrier to use by the Consumer increases the likelihood of being viewed by End-Users. Would such a service ever offer the EntityManagement interface? Why not? This would be a means of letting (but not requiring) the Consumer (as the gateway to the End-User) customize the settings of the service in a manner the Consumer chooses. Gil Tayar <Gil.Tayar@webcol To: Rich Thompson/Watson/IBM@IBMUS, lage.com> wsrp-wsia@lists.oasis-open.org cc: 10/28/2002 01:08 Subject: RE: [wsrp-wsia][I#106] Proposed resolution: Uniqueness of PM Entity Handles Rich, There is no contradiction. The contradiction is in the name "registrationHandle" which is a handle which _must_ exist without Let's look at it from the Entity Management interface POV. Somwehere buried in that interface is the "registrationHandle". Now this handle _must_ have meaning _without_ any need for a registration, so in essence it can't be called "registrationHandle". That is why I proposed renaming it. Renaming it will do the job. The question is to what? I agree that "consumerHandle" is confusing for the reasons you pointed out. How about "relationshipHandle"? "relationshipHandle" works terminology-wise: "a registration creates a relationship"; and: "the scope of every handle is the scope of the relationship, whether determined out of band or in-band". Gil -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Mon, October 28, 2002 15:04 To: wsrp-wsia@lists.oasis-open.org Subject: Re: [wsrp-wsia] RE: [wsrp-wsia][I#106] Proposed resolution: Uniqueness of Entity Handles People found it confusing to have this named consumerHandle as a Consumer MAY have several of them with any one particular Producer. You have a contradiction between reminding us that registration is optional and desiring this to be scoped to a registrationHandle (which is the current statement). I could see adding a parenthetical statement extending this uniqueness to the Producer scope for those Producer's not requiring Consumers to register (either in-band or out-of-band). Gil Tayar <Gil.Tayar@webcol To: wsrp-wsia@lists.oasis-open.org lage.com> cc: Subject: [wsrp-wsia] RE: [wsrp-wsia][I#106] Proposed resolution: 10/27/2002 06:50 Uniqueness of Entity Handles AM Rich, I believe we should not define entityHandle to be scoped to something that is optional. What happens if no registration was done? I believe this should be scoped to "registrationHandle". Actually, to go even further, I would say that registrationHandle should be just named "consumerHandle", or maybe "consumerId" to denote its persistence, because it may not even have created through a registration process. -----Original Message----- From: Gil Tayar [mailto:Gil.Tayar@webcollage.com] Sent: Sun, October 27, 2002 13:43 To: wsrp-wsia@lists.oasis-open.org Subject: [wsrp-wsia][I#106] Proposed resolution: Uniqueness of Entity Handles Issue: 106 Title: Uniqueness of Entity Handles Resolution Date: 10-Nov-2002 Status: Tentative resolve Proposed Resolution: Draft v0.81 (small grammar update) describes an entityHandle in section 7.1.4 as "An opaque and invariant handle, unique within the context of the Consumer’s registration, which the Producer is supplying for use on future invocations targeted at the new entity." ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC