[Fwd: WS-Addressing and URIs]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Interesting comment on WS-Addressing and URIs (as we move into our 
correlation discussion today). Thank you.

--- Begin Message ---

• From: Mark Baker <distobj@acm.org>
• To: www-tag@w3.org
• Date: Mon, 30 Aug 2004 10:50:19 -0400

Hi all,

I believe there to be a rather large Web-architectural flaw with the
recent WS-Addressing submission[1] that I wanted to raise with the TAG.

The spec itself covers a lot of ground, but I'm primarily interested in
section 2[2], "Endpoint References".  As you might expect from the use
of the word "reference" (and even the title of the spec, "addressing"),
there is considerable overlap with URIs.  More specifically, what the
WS-Addressing spec appears to be doing is actually *discouraging* the
use of URIs for identification, and instead replacing them with an XML
document (the EPR).  Consider the following example[3] of such a
document;

<wsa:EndpointReference xmlns:wsa="..." xmlns:fabrikam="...">
   <wsa:Address>http://www.fabrikam123.example/acct</wsa:Address>
   <wsa:ReferenceProperties>
       <fabrikam:CustomerKey>123456789</fabrikam:CustomerKey>
   </wsa:ReferenceProperties>
   <wsa:ReferenceParameters>
       <fabrikam:ShoppingCart>ABCDEFG</fabrikam:ShoppingCart>
   </wsa:ReferenceParameters>
</wsa:EndpointReference>

In that example, the URI "http://www.fabrikam123.example/acct"; is used
to identify a "gateway" of sorts, beyond which one is left requiring the
use of the CustomerKey value for the actual identification of the
customer account resource.  Can any of the WS-Addressing submitters
explain why the customer account isn't just identified by a URI such as
this one?

  http://www.fabrikam123.example/acct/123456789

(I'm ignoring the reference parameter there for the moment since it's
role is slightly different than the property, and should not, arguably,
be part of the URI)

If the issue here is that Web services needs to license a client to
peek into an identifier (which seems to be the case, otherwise why
would you standardize it?), I would recommend that they define a new
URI scheme, say, "epr".  This would at least be consistent with the
webarch good practice item[4] which states;

"Agents making use of URIs SHOULD NOT attempt to infer properties of the
referenced resource except as specified by relevant specifications."

But on the other hand, I don't see why this licensing is required, and
therefore why a relatively opaque http URI wouldn't suffice.

Thanks.

 [1] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
 [2] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464317
 [3] http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/#_Toc77464320
 [4] http://www.w3.org/TR/webarch/#pr-uri-opacity

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

--- End Message ---