RE: i0001: EPRs as identifiers

In general, I think we've run the road on this.  I have not volunteered
to write use cases for Ref Props/Params.  I have volunteered to write up
a comparison of EPRs and URIs, and I see nothing in your message that
disputes the comparison.

More comments inline.
> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Thursday, November 18, 2004 7:06 AM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: RE: i0001: EPRs as identifiers
> 
> 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.
> 

David, are you fully reading what I've written?  I've now said at least
3 times that xml structures are useful for identification purposes and
given multiple examples, even specifications that are in an open
standards process.  I'm sure a simple google search can help you find
WSDM, Grid, WS-RF specifications.  I'm not going to do any more work on
this.

> > 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.ht
ml
> [[
> 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*.

Issue #1 is about the use of EPRs as identifiers, and that includes both
Ref properties and parameters.  The best I can do is guess that you are
saying Ref Properties aren't justified as identifiers, but Ref Params
are justified as identifiers.  If you are saying that both aren't
justified, then it's a waste of time to differentiate between params and
props.

> 
> > 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.

I was asked to provide a comparison of EPRs and URIs, and I even used
the official REST properties to do so.  We do not have a formal
deliverable for Use Cases and I don't think it's part of this
deliverable.  You're trying to move the yardsticks on me, and I'm not
playing that game.  

> 
> > 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?
> 

That is the trade-off.  The choice of partitioning the URI space or into
the message body via Reference Props/Params is in the developers hands.
I've described the trade-offs between the two.

Received on Friday, 19 November 2004 07:08:12 UTC