RE: Issue #1 proposed resolution

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.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Mark Baker
> Sent: Sunday, January 16, 2005 8:49 PM
> To: public-ws-addressing@w3.org
> Subject: Re: Issue #1 proposed resolution
> 
> 
> 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).
> 
> It sounds like we're pretty close here.
> 
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Monday, 17 January 2005 06:17:41 UTC