« Michael Kay on data constraints | Main | Monster Oriented »

Son of the Morning

Mark Baker is not impressed with the GUT of webservices addressing:

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

Somebody please tell me why on earth that isn't a URI? You know, something like;
http://www.fabrikam123.example/acct/123456789?ShoppingCart=ABCDEFG

I'm in agreement with Mark about this spec, but... oh, go on then. Let's have a dialog.

Let's see - the XML structure is by design decomposable into constituent parts, ie it's a tuple with angle brackets. URIs are not like this - they're pure identifiers. According to a W3C TAG dictat, URIs are supposed to be treated opaquely, but there's no getting around the fact that a huge body of deployed web software is totally reliant on composing and deconstructing URIs. In the real world they are used as tuples/dicts and they are laden with semantics.

When made that URI, we in design terms lost information by moving from a tuple to a literal. However in implementation terms we're going to frig that identifier for information embedded in it. And that's cool - the URI is lexically designed to be friggable.

But if that's so, and tuples are useful means to pass information between client and server, then why is the GUT called WS-Addressing and not WS-IdentificationByDescription? ;)


August 14, 2004 12:04 AM

Comments

Mark Baker
(August 14, 2004 02:28 AM #)

Actually, if you check webarch, it says you shouldn't peek into URIs for information that no spec licenses you to. So that's true, you shouldn't peek into my example http URI for shopping cart info, since the http scheme doesn't allow it.

So why not just mint an "epr" URI scheme that does license you to do so? Then you'd get all the advantages of whatever the EPR spec is trying to enable, combined with the advantages of a URI.

FWIW though, I don't believe EPR consumers need to peek into an EPR either, which is why I also think that mostly-opaque http URIs likely suffice for the needs of those who created WS-Addressing.

Jon Hanna
(August 17, 2004 07:33 PM #)

I'd go further and say it's okay for a spec to say "The HTTP URIs used here are composed thusly:" and then detail something that the processes producing the URIs are mandated to follow and the processes consuming them can rely on.

However when this hits the wider web, for instance if a browser or parser not specifically created for the task at hand or a caching proxy sees it, then they must not make guesses about the URI based on common conventions or anything outside of the specs they are based on (HTTP, URI, XML Base, RDF etc.) and must treat them as opaque.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1385