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/