Re: Issue #1 proposed resolution

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