[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