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 07:30:14 UTC