 |
 |
I think we've gone far off into territory nobody else on the list is likely to care about. People will start unsubscribing :-) So let me try to wind this subthread down by seeing if I understand what you're arguing for: If you are saying that HTTP URIs should always be able to be used to retrieve a resource (allowing for redirection, human fallibility, etc.), then we are in violent agreement. If you're arguing that URIs aren't names, I can only point at the RFC and say "I didn't make the rules." If you're arguing that it's incorrect to use an HTTP URI to identify something that isn't a resource on the web, then we disagree. There's a whole world of (ongoing) discussion of methods for doing just this. http://www.w3.org/2001/tag/awwsw/issue57/latest/ for example, has an overview of the state of play. On Apr 24, 2013, at 5:12 , Scot Mcphee <[log in to unmask]> wrote: > > On 24/Apr/2013, at 07:28 , Hugh Cayless <[log in to unmask]> wrote: > >> >> On Apr 23, 2013, at 17:03 , Scot Mcphee <[log in to unmask]> wrote: >> >>> A http URL is and in itself an actual digital resource: hyper-text transfer protocol. >> >> It really isn't. It's a name that the web infrastructure knows how to handle: look up the IP address of the named server, open a connection to it using the protocol named in the URI scheme, ask the server for the resource named in the path. The URI is not the resource. The server might not give you the named resource—it might forward you on to something else instead. > > All of which should be done with HTTP semantics: 301/303/307/308. Not document semantics (e.g. here's a piece of XML that if you parse it, it will tell you the answer you seek is found somewhere else). I would never argue otherwise. > > However, "the URI is not resource"; I disagree somewhat. It's a pointer (or a reference) to a representation of a resource. OK so as a pointer (and I mean this term specifically to mean a indirect reference to a location, like a C pointer), it isn't the representation itself, precisely, but in practical reality, it is treated as such. The idea of representation really means in practical terms: "document format". Building addresses may be a better analogy. My address tells you how to find my house. But my address is not my house. It's a name that provides you (hopefully) enough information to locate the building. > > Consider URIs broken down into REST semantics. If you try to GET a resource and it returns "404 not found" you might try to POST to the URI in order to create a representation. Also normally you'd expect the system capabilities to convert that representation to the other representations that clients may request from it - maybe it will only therefore accept a canonical (to it) representation such as a particular XML format, e.g. TEI, which it can save in its local data store. > > So I think to say that a URI - which starts in "http" - which doesn't result in a representation, or meta-data about a representation - the HTTP status codes, and perhaps certain HTTP headers being most of the meta-data you'd need - I'd say that is a broken URI. By putting "http://" on the front of a URI you are promising things about the protocol interaction, in a technical sense. I get the feeling you might think I was arguing for making up random HTTP URIs that can't be used to retrieve anything. That was not my intent. I was just pointing out that HTTP URIs are every bit as good names for things as URNs are. > >>> I'd tell you your text was faulty as the URL does not resolve. Alternatively, I would try to POST to it to create the resource. >>> >>> >>> I think despite whatever that IETF RFC says, a http URL implies there is a representation of some kind at the other end (a '404' is a representation - metadata - about the object which is well defined in the HTTP specification). >> >> An HTTP URI certainly implies that you can use it to retrieve a resource. But if you read up on linked data, you'll see that people use HTTP URIs to name things that can't directly be retrieved over HTTP all the time. >> > > I am made painfully and well aware of their use as such in XML schemata every day. And it is a big fault in XML, IMHO. People may do this - and standards, e.g. SOAP WS-*, etc may mandate it - but that, in my opinion, is merely one of the very many things wrong with those standards, and the usages that people put them to. You may not like it, but they're not breaking any rules. SOAP makes me all stabby too, but I can only argue that it's stupid, not that it's wrong. > > Scot. > > >