RE: i0001: EPRs as identifiers

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.

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.

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

Cheers,
dave

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org]
> Sent: Tuesday, November 16, 2004 11:30 PM
> To: public-ws-addressing@w3.org
> Cc: David Orchard
> Subject: Re: i0001: EPRs as identifiers
> 
> DaveO,
> 
> Regarding http://lists.w3.org/Archives/Public/public-ws-
> addressing/2004Nov/0351.html
> 
> The analysis you gave brings up some very good issues, but I don't
think
> it goes far enough to justify the conclusion that WS-Addressing should
> include Reference Properties.
> 
> 1. The example you gave seems to *assume* that XML identification
> mechanisms are needed in this context:
> 
>         "Many applications use XML as the
>         mechanisms for identifying their components."
> 
> I don't think this is a reasonable assumption, because certainly
> if you assume that XML identification mechanisms are needed, then
> XML identification mechanisms will appear to be the easiest way to
> achieve them.  Rather, I think the question is: *Are* XML
identification
> mechanisms needed to identify a Web resource?  If so, why?  What are
> the use cases that *require* them, where URIs would be inadequate?
> 
> 2. I think your example is inadequate, because it obscures
> the distinction between RefProps and RefParams, and this distinction
> is key to the issue.  Your example presents CustomerKey as a Reference
> *Property*, whereas it seems more natural to treat it as
> a Reference *Parameter*, because in most cases I would assume that
> the service interface would be the same regardless of the value of
> the CustomerKey.  If you have a realistic use case that requires a
> different service interface, I would be very interested to see it.
> 
> Omri Gazitt hit the nail on the head in calling out the distinction:
> http://www.gazitt.com/OhmBlog/permalink.aspx/deea5866-4da7-4774-b7c6-
> 4daa7aabaec9
> [[
> A useful analogy: in the URL http://foo/bar?param1=value1, http://foo
is
> the wsa:Address, "bar" is the RefProp, and "param1" is the RefParam.
> ]]
> The reason the distinction is important is that it is easy
> to think of http://foo/bar as identifying a separate
> service than the service at http://foo, whereas the "?param1=value1"
> part might reasonably be viewed as merely supplying an application
> parameter to http://foo/bar, rather than identifying yet another
service.
> 
> 3. Under "Evolvability: Advantage of EPRs", you state
> [[
> Separating the reference property from the URI may make it easier for
> service components to evolve.  A service component may know nothing
> about the deployment address of the service from the reference
> properties.  This effectively separates the concerns of identifiers
into
> externally visible and evolvable from the internally visible and
> evolvable.  For example, a dispatcher could evolve the format it uses
> for reference properties without concern of the URI related software.
> The use of SOAP tools - for parsing the soap header for the reference
> properties - or xml tools - such as an xpath expression on the message
-
> allow separate evolvability of components.
> ]]
> 
> I don't see why this could not apply equally to a URI that is
internally
> parsed into a stable portion and an evolving portion -- the evolving
> portion
> corresponding to the RefProps.  Are you implying that EPRs have an
> implicit
> expiration time that URIs do not have, and thus the service can freely
> evolve them without worrying about the client remembering old values?
> 
> --
> 
> David Booth
> W3C Fellow / Hewlett-Packard

Received on Wednesday, 17 November 2004 18:39:03 UTC