- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Sat, 18 Jul 2009 22:35:30 +0200
- To: Pat Hayes <phayes@ihmc.us>
- Cc: "www-tag@w3.org WG" <www-tag@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
[resent from the correct address] lör 2009-07-18 klockan 12:55 -0500 skrev Pat Hayes: > Unfortunately, this use of 'map' terminology only confuses things even > further. Many cases of the denotation relationship between URIs and > resources cannot be mapped by any server, if 'map' refers to any kind > of computable operation. And the point is? HTTP does not care how URIs map to resources (in any terminology, but see the end for what resource is in HTTP terminology), it's the role of the server implementers and webmasters/authors to define such relationships if any. For some URIs the mapping is trivial and often even 1-1 (but may be n-m), for some it's less obvious, and for some it may even be impossible. HTTP does not care. What HTTP cares about is to provide means for representing this at suitable level of detail as needed for proper operation of HTTP where the proposed 303 response to GET is one possible outcome. HTTP operates with URIs and the representations of resources servers return in response to requests to those URIs. End of story. Such accesses MAY render effects outside HTTP (such as items being shipped to you from a web shop, robots making some move, some electron bouncing around, a valve opening/closing somewhere etc) but those effects are outside of HTTP specifications. In addition it places certain protocol level restrictions on how servers may behave when there is many possible representations accessible via the same URI, but that's a different topic. > No, that is not what I said, and your misunderstanding of what I said > is typical of the communication problems we find in these discussions. > The relationship of denoting (referring to, naming, being a name of) > is, prima facia at least, completely unrelated to issues of resolving > on servers. Servers and networks and transport protocols simply have > nothing to do with naming, Good. So what is your argument exactly? At the level, view and context of HTTP, ignoring the rest of the world. > The picture given by Richard, and to which I was reacting in the above > quote, was this. URIs denote things. The HTTP GET takes a URI and > resolves it to a server (not a resource) which responds with a > **representation of the denoted resource** attached to a 200 code, if > it has a suitable such representation. ("Suitable representation" here > has to be given further gloss, as it is a nonstandard usage.) In the context it simply means that the server is responsible to determine if there is a representation available suitable to be used when building the response and what that is if any. HTTP does not really care how the server decides that. > That > makes sense, given that we further specify that some resources just > don't have representations, so the server must issue a 303 code in > those cases. Yes, or to be exact when there is no suitable representation available to be used for the HTTP response to this request for a valid URI which do refer to some kind of resource as identified by the server. > Note that the represented, requested resource itself > plays no part in this picture: it is all about servers and > representations of resources. Fully agree. > Well, part of the passion in these exchanges arose from Richard C's > insistence that HTTP said *absolutely nothing* about meanings of URIs, And it doesn't. That's part of the application of URIs to something, not HTTP itself. For most the semantics of such application of URIs is even outside the URI specifications and solely left to the actual implementation/application of URIs. > so I am surprised to hear that the HTTP protocol intends any notion of > meaning at all. Not in my world. > But more to the point, it is now simply a fact that > URIs are used as denoting names on the Web. HTTP does not really care about this either. > Published W3C specs require them to play this role. At the level of HTTP, or at the level of user experience of URIs when accessed via some user agent? And what does those unnamed W3C specs have to do with the HTTP specifications? > OK, that is good. It would help if that were stated explicitly, since > the same server and the same resource can be located/identified by a > different URI also. The wording which I was objecting to refers only > to resources, so this point is not clear, as the same resource might > be identified by several URIs. The wording is in the context of how a sever can build a response to a request for a specific URI, with no relevance to requests for other URIs. HTTP does not care much if the same resource has multiple URIs, with just one minor optional exception (Content-Location). > The suggested wording refers to the 'requested resource'. Yes, as defined by HTTP. Not in the general English meaning (whatever that is, I would not know what a "requested resource" is in general English, or even Swedish for that matter). > You here are talking about the 'requested URI'. Yes, as a slight simplification I choose to ignore server driven negotiation in this discussion, but that's besides the point. > These are not the same. Which is correct? In the terminology defined by HTTP the difference between an (HTTP-)URI and resource is more of a special case, and not related to any of what you talk about. resource in HTTP terminology is NOT the general resource of anything you seem to refer to, but in specific the resource within the server which holds the information and/or processing required to build a suitable representation to be used within HTTP (or as close to that you can get). Yes it's a simplification, but defining or assume anything about resources anywhere beyond that is outside of HTTP scope and nothing HTTP cares about and is left to the application of HTTP and/or URIs. HTTP does not care or imply anything about how those resources map to any real-world or abstract resources beyond the operation of HTTP. To quote the specifications: p1-messaging, 2.1 Uniform Resource Identifiers HTTP does not limit what a resource may be; it merely defines an interface that can be used to interact with a resource via HTTP. [and reference to RFC3986 for further details about URI and resource in general] p1-messaging, C. Terminology resource A network data object or service that can be identified by a URI, as defined in Section 2.1. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways. Note: "resource" in 2.1 above refers to the more general RFC3986 meaning, in the rest of the HTTP documents it generally refers to the HTTP definition of resource. > > which includes matching the intended > > meaning of that URI by whatever name scheme the server implements > > No, it cannot possibly do that, in many cases. No implementation of > anything is ever going to match anything to Julius Caesar, who has not > existed for around 2000 years. Not what I was talking about, and I don's see what your point with this is either. This response was in response to your talk about a resource (in general terms) having multiple URIs with different meanings. My response is that it's the servers role to select a suitable representation of the resource based on the meaning of the URI. A server ignoring such meaning as defined by the server would be in error with itself. In the terms of HTTP each of those URIs actually refer to a resource of it's own as they have different URIs and meaning, even if those resources perhaps are very closely related. > Resources aren't sent in response, representations are. Did you mean > representation? Yes and no. The resource to be used when making an HTTP representation of the requested resource. But see above for the HTTP meaning of resource in this context. Regards Henrik
Received on Saturday, 18 July 2009 20:37:16 UTC