Re: Issue #1 proposed resolution

I think the pragmatic view on RefProps/RefParams has to be that they will
stay (rightly or wrongly, there are implementations and specifications out
there that now rely on them). I agree that the term "identifier" can be
contentious. However, so can the term "state". How about just calling
it/them "additional information that referencing specifications [aka using
specifications] or implementations need in order to ultimately address the
endpoint service"? That way we're not saying *what* goes in there, only
*why*.

Just my 2 cents worth.

Mark.

----
Mark Little,
Chief Architect,
Arjuna Technologies Ltd.

www.arjuna.com


> Hi Hugo,
>
> I am glad you see this as a step towards successfully closing this issue;
> reading your last main on this topic I realized this proposal was pretty
> close to your view also. Two comments:
>
> 1. You are right that a proposal compatible with this thinking would
> certainly require removing from the text everything that would seem to
> imply that EPRs and/or ref. props. are identifiers (I made a proposal for
> this some time ago).
>
> 2. I think the ref. properties vs. ref. parameters discussion is not
> central to issue 1 and could be cleanly separated. If we assume that the
> only identifier in an EPR is the Address field, and characterize both
> properties and parameters as "state" associated to the interaction, then
> the difference between the two boils down to whether a change in one of
> them should be interpreted by the consumer of the EPR as implying a
> possible change in the policies that affect the interaction. Note that a
> change of policies is in no way associated to a change in "identity" or
> anything like that, as policies can change very dynamically during the
> course of the interaction (depending of the date or time of the day) w/o
> any implication that the "resources" or parties involved have changed.
>
> If people are concerned about that issue (props vs. params) I suggest we
> separate it into a different issues.
>
> Paco
>
>
>
> |---------+----------------------------------->
> |         |           Hugo Haas <hugo@w3.org> |
> |         |           Sent by:                |
> |         |           public-ws-addressing-req|
> |         |           uest@w3.org             |
> |         |                                   |
> |         |                                   |
> |         |           01/17/2005 11:14 AM     |
> |---------+----------------------------------->
>
>---------------------------------------------------------------------------
----------------------------------------------------------|
>   |
|
>   |       To:       David Orchard <dorchard@bea.com>, Mark Baker
<distobj@acm.org>                                                      |
>   |       cc:       public-ws-addressing@w3.org
|
>   |       Subject:  Re: Issue #1 proposed resolution
|
>
>---------------------------------------------------------------------------
----------------------------------------------------------|
>
>
>
>
> Hi Dave and Mark.
>
> This is indeed very encouraging.
>
> * David Orchard <dorchard@bea.com> [2005-01-16 14:16-0800]
> [..]
> > 1. Consider a stateful interaction model where ref. properties are
> >
> > interaction data and the full state of the interaction (in the form of
> >
> > actual business data: a shopping cart, for example); this usage follows
> >
> > the canonical stateless implementation that http cookies allow. In fact,
> >
> > the semantics of ref props in this usage case are not very different
> >
> > from cookie semantics except for the fact that WS-Addressing does not
> >
> > define an EPR lifecycle. The EPR in this situation acts as a mere
> >
> > packaging mechanism for transmitting to the service requester the URI
> >
> > address + state that is characteristic of a particular interaction. In
> >
> > particular, there is only one identifier involved here, the URI
> >
> > providing the network address. The state represented by the ref. props.
> >
> > has no identification function in this case.  The EPR is nothing but an
> >
> > XML envelope for the two.  To reiterate, the EPR is not an identifier
> >
> > but a container used to specify echoed state information.
>
> Aren't you describing a use for reference parameters here, and not
> reference properties, then?
>
> > 2. The use of EPRs and ref props as a server side "identifier"
> >
> > (as opposed to client side identifiers) is another possible and probable
> >
> > use case. Here, the combination of URI and ref. props. is used by the
> >
> > infrastructure to retrieve stateful artifacts associated with the
> >
> > interactions. Typically, in these cases the internal implementation of
> >
> > the server side provides for mechanisms to compare two EPRs for
> >
> > "sameness" and can operate with proper id semantics internally.
> >
> > Reference properties carry server side specific data (not business data
> >
> > as before).
> [..]
>
> * David Orchard <dorchard@bea.com> [2005-01-16 22:17-0800]
> > Yeah, we should remove that wording as it's true yet implies the client
> > will make use of the EPRs for identification purposes.  I have no
> > problems with RefPs being used for identification, but it's by no means
> > the only case.
>
> So, if only the server-side is concerned with what RefP's are used
> for, and that the wording about the identifying role of [reference
> properties] should be removed, then doesn't that it means that
> [reference properties] and [reference parameters] are equally opaque
> bags of XML data from the requester's perspective?
>
> * Mark Baker <distobj@acm.org> [2005-01-16 23:48-0500]
> > On Sun, Jan 16, 2005 at 06:51:59PM -0800, David Orchard wrote:
> > > EPRs aren't defined to be identifiers.  An EPR may contain
identifiers,
> > > but it may contain state.  Therefore, there's no conflict with EPRs
(as
> > > a class) as they stand with advice to use URIs for identifiers.
> >
> > This is very encouraging, and if that were the case I agree that there
> > would be no issue.  But for this;
> >
> > "A reference may contain a number of individual properties that are
> > required to identify the entity or resource being conveyed."
> >  --
>
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464317
> >
> > Your RefProp example in your initial post didn't use them as identifiers
> > though; it used them as RefParams in fact.  So I'll go out on a limb and
> > ask; would you be content with removing RefProps?  Alternately, would
> > you be content with saying that RefProps shouldn't be used for
> > identification?  (though I guess you'd then have to distinguish them
> > from RefParams, but perhaps you have some ideas about that).
>
> I think that your alternative only holds true if [reference
> properties] are not considered by the client side for metadata
> comparison purposes. If it were not the case, then [reference
> properties] would be identifying this metadata about the endpoint.
>
> If we agree on this, then I think that we are saying [reference
> properties]' use is essentially similar to [reference parameters]',
> and that they are basically the same. Are we?
>
> Cheers,
>
> Hugo
>
> --
> Hugo Haas - W3C
>  mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
>
>
> #### signature.asc has been removed from this note on January 17, 2005 by
> Francisco Curbera
>

Received on Wednesday, 19 January 2005 22:43:35 UTC