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

RE: i0001: EPRs as identifiers

From: Francisco Curbera <curbera@us.ibm.com>
Date: Mon, 22 Nov 2004 13:31:51 -0500
To: David Booth <dbooth@w3.org>
Cc: David Orchard <dorchard@bea.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF4B1FB3A8.0611BF6E-ON85256F54.00647C74-85256F54.0065CB41@us.ibm.com>


Just to add one comment to DaveO's answer. Different customerKeys could
perfectly be associated with different policies, so I don't think your
argument against them appearing as reference properties is valid.


                      David Booth                                                                                                              
                      <dbooth@w3.org>                 To:       David Orchard <dorchard@bea.com>                                               
                      Sent by:                        cc:       public-ws-addressing@w3.org                                                    
                      public-ws-addressing-req        Subject:  RE: i0001: EPRs as identifiers                                                 
                      11/18/2004 10:06 AM                                                                                                      

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:
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*:
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 Monday, 22 November 2004 18:31:57 UTC

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