W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2005

RE: Issue #1 proposed resolution

From: David Orchard <dorchard@bea.com>
Date: Sun, 16 Jan 2005 22:17:31 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0CF65D23@ussjex01.amer.bea.com>
To: "Mark Baker" <distobj@acm.org>, <public-ws-addressing@w3.org>

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.


> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> 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
> > but it may contain state.  Therefore, there's no conflict with EPRs
> > 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
> though; it used them as RefParams in fact.  So I'll go out on a limb
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC