W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: i0001: EPRs as identifiers

From: David Booth <dbooth@w3.org>
Date: Thu, 18 Nov 2004 10:06:17 -0500
To: David Orchard <dorchard@bea.com>
Cc: public-ws-addressing@w3.org
Message-Id: <1100790377.3681.82.camel@nc6000.w3.org>

On Wed, 2004-11-17 at 13:38, David Orchard wrote: 
> 1. Qnames are good as identifiers, as in "myns:component".  I can see
> having a list of properties and values, with the property names being
> QNames.  Grid, WSDM do this.  There are other xml languages, like
> XQuery, that are emerging that can be used to identify components as
> well.

Yes, qnames are often used to identify components within an XML
document, but that isn't the issue AFAIK.  The issue is that we're
talking about using them to identify Web resources -- specifically WS
endpoints.  Can you point us to use cases that demonstrate that URIs are
inadequate for identifying Web resources?   (Ideally WS endpoints?)  If
Grid and/or WSDM have such use cases, pointers would be very helpful.

> 2. I'm not sure what you saying is incorrect about the motivation for an
> echoing facility.  Whether it's ref props or params, there is an echoing
> facility.  As for Omri's post, you should check out the comment that I
> left a few days ago.

Yes, your comment said:
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0359.html
[[
I think in my discussion I focused on Ref properties, and I did not
mention Ref parameters.
]]
My point was that your example represented CustomerKey as a 
Reference *Property*, whereas it would have been more
natural and appropriate (in most cases) to represent it as a 
Reference *Parameter*, because it is unlikely that a different value
for CustomerKey would result in a different service interface.  
Thus, I don't think your example adequately
motivates the need for Reference *Properties*.  The difference between
the two is important.  We cannot sensibly discuss the need for 
for Reference *Properties* if they are not clearly distinguished from
Reference *Parameters*.

> 3. A URI could be separated into different sections, but that's not the
> issue.  The issue is that applications may want identifier information
> that is protocol independent 

The description of Reference Properties in the WS-Addressing spec 
explicitly says that they are protocol *dependent*:
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464318
[[
The interpretation of these properties (as the use of the endpoint 
reference in general) is dependent upon the protocol binding and 
data encoding used to interact with the endpoint.
]]

> or in a separate identifier space.  

We need to see use cases that demonstrate the need for a separate 
identifier space.

> This
> enables loose coupling, particularly separation of concerns.  By having
> the URI and Refs separate, then completely orthogonal software can work
> on each piece. 

Can't an implementation choose to do the exact same thing by
partitioning the URI instead?

-- 

David Booth
W3C Fellow / Hewlett-Packard
Received on Thursday, 18 November 2004 15:06:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT