- From: Larry Masinter <LMM@acm.org>
- Date: Tue, 18 May 2010 07:59:16 -0700
- To: "'Jonathan Rees'" <jar@creativecommons.org>
- Cc: <www-tag@w3.org>
re inline comment: JAR >> 2) http: URIs make reliable names only when HTTP exchanges with the >> URI as request-URI play no role in determining what they name. LM: > I don't understand what you mean in "determining what they name". > I think of the act of party A sending party B a URI as a speech > act. Party A has some idea of what they want party B to understand, > sends a URI X to party B, and party B interprets the URI X > in some context. Something is 'reliable', I guess, if it's > useful for communication and the two parties are interoperable. > > If I send you "http://larry.masinter.net" and you *don't* actually > use the HTTP protocol to retrieve the web page there, well, what > *do* you use? The DNS WHOIS database? > How about a web cache? Or maybe the 'representation' was bundled as > part of a software installation, and never sent over HTTP. Or maybe a > different protocol such as some fancy high-performance successor to > HTTP was used. Or maybe the URI is being used for coreference and not > in relation to 'representations' at all - e.g. a namespace URI. > I think this is a theme that Roy has been pounding on for years now, > so you are probably familiar with it. If you haven't bought into it so > far, well OK, I'll accept that as being your position, as this is a > matter of judgment, not fact. But there are consequences to the > position that are sort of inconvenient. URIs are not uttered completely without context. Just as the context of a word in natural language can determine its meaning in that context, the same can be true of URIs. While was a design goal of URIs to be "uniform"--to carry the same meaning in all contexts-- meeting this design goal depends on the designers of URI contexts to share and meet that design goal. The hypermedia context (as a hyperlink in HTML, PDF, installed software) includes the possibility of web caches, and web caches are expected to be (relatively) transparent, the purpose of the cache is to optimize the transaction without changing the meaning or results. The XML namespace design creates a context where the meaning of a URI in an xmlns is different than the meaning if the URI were to appear in a@href or img@src. This part of the XML namespace design is not without controversy, detractors, and negative consequences. The URIs in <img xmlns="http://image.example.com/jar"> and <img src="http://image.example.com/jar"> have different meaning, "identify" different things (the former a namespace, the latter an image). It is definitely inconvenient. It's inconvenient that the lifetime of reliability for URIs-as-hyperlinks doesn't always meet the requirements for reliability lifetime of XML namespace designations; it is inconvenient that URIs-as-hyperlinks are intended to be accessed, while URIs-as-namespaces are not. It is convenient that the process of obtaining a namespace name is usually well understood. It's inconvenient that there is still no general agreement about good operational practice for what, if anything, to put as the retrieved resource for a namespace URI. I'm not sure what I'm not buying into, though. I agree that a "http" URI doesn't always imply using the HTTP protocol to access the data from the origin, but I also think that the variation in meaning is mainly disambiguated by the context of use. Does that help? Larry -- http://larry.masinter.net
Received on Tuesday, 18 May 2010 15:59:56 UTC