In my perceived role as master of stating the bleeding obvious, I'd just like to point out that a URI is for "identifying an abstract or physical resource", and doesn't mandate the actual location or means of reaching said resource:
- When a browser does a GET on http://blog.whatfettle.com, does it open a socket to port 80 on the IP address resolved by the DNS address blog.whatfettle.com. Probably not if you're behind a firewall.
- If your browser requests http://google.co.uk from http://google.com, will it get the page it expected? Possibly.
- If I "telnet localhost 80" and type "POST mailto:santa@northpole.org HTTP/1.0^M", will my message get through? Maybe, or at least according to Mark
- Oh, and when I give Amazon my home address, do I care which courier they use? Not really.
Of course all that ignores how you know where and how to switch protocols or locations. Let's just say that's a simple matter of configuration.
Note that I've also neatly ignored the whole "what is a resource" debate: a dog or a picture of a dog? As everyone on the WS-Addr WG now knows, a URI points to a Resource, and a resource is something identified by a URI, right?
Update: i composed this during the WS-Addressing telcon last night, about the same time Noah raised this new TAG issue.
Hmmm.... and you've stayed largely in the pre-Semantic Web world where no attempt is made to make statements about the things identified by a URI. The transition that makes things problematic is when we try to say 'things' about 'things' which is what RDF does in spades.
In the pre-SW world... no harm done if you conclude the resource is a 'dog' and I conclude that the resource is a 'picture of a dog'. In the post-SW world it would be odd to say that a 'picture of a dog' has two parents.
However, that said, one can mis-speak in natural language and one mis-speak on the semantic web. Some would say "...deal with it!" and... if you want to say things about 'dogs' and 'pictures of dogs' (see ) mint different URI for each (even if they share some representations in common).
Ooops, failed to get the URI to show:
(see http://photos5.flickr.com/6108852_5be372aadc.jpg)