RE: Naming things with hashes (not #, but e.g. md5)

You're not understanding me, and I'm getting tired of trying to explain.

For example: 
> Just to be clear, the hr14 resolution has two parts, a 2xx case (a) and a 303 case (b).

But the hr14 resolution is incoherent because it is a "resolution" to a senseless question, and thus "cases" are meaningless. There is no "2xx case" and a "303 case", any more than there is a "404 not found" case and a "DNS error, server not found" case.  

If sender A sends 

    <a href="http://example.org/path">something</a> 

to recipient B inside a message labeled "text/html", that message expresses the intention that if B displays the result of the message, it will display 'something' with a hyperlink which, when clicked or selected, will attempt to connect to example.org with path /path using the HTTP protocol; other messages in other formats with hyperlinks (PDF, flash, XML, SVG) or with other URI schemes (ftp, data, mailto, etc.) have similar or related meaning.

I can try to explain by analogy, once more.  If I tell you, "The sky is falling", 
then what I say is independent of what the OED or the American Heritage
dictionary say about the words "sky" and "falling". There are references
you can consult to discover what I might have meant, and our conversation
is more reliable if I make reference to reliable dictionaries in which you can
discover definitions of terms I use if those terms are not in (our) common
use.  But the meaning doesn't inherit from the dictionary or whether you 
have one or change if your dictionary burns up.

While "follow your nose" may be a "good practice", meaning doesn't
depend on good practice being followed. The meaning of an instance
of XML doesn't depend on whether someone has bothered to populate
the namespace URI's web server with interesting information about
the URI, and doesn't change when the web site is put up or taken down.

The reliance on 200 vs 303 vs. 404 vs. "server not found" DNS errors may be
an artifact of some particular processing systems that actually rely on
attempting retrieval from URIs used in RDF, but that dependency is an
artifact of those (poorly designed, IMHO) processing systems, and not
on the "meaning".

And no, the HTTP working group scope does not cover defining the
meaning of HTTP URIs outside of a URI as a signifier of invocation of
the HTTP protocol with a particular host address found within the
HTTP URI, so saying that your interpretation is "enshrined in HTTPbis"
is nonsense.


>  If
> I ask what an occurrence (in some context) of a name "means", I'm
> asking what the party who wrote that occurrence intended when they
> wrote it. 

I think that's an impoverished model of communication which you insist on sticking with, and which leads to the same senseless conclusions.  I don't think we're going to make progress on clarification here if you insist on framing the question in the way you are framing it, and don't think it is worth TAG time to discuss this any more. 

The sender (A) is communicating with the receiver (B) with a message M that includes a URI U.  U participates in the communication, and the communication of M is effective if A and B share a mutual understanding of M and U's role in it.

If M is HTML and U appears in a@href, the "meaning" of U in that context is pretty widely understood as establishing some expected behavior in B's software when B clicks on the link, at least for some URI schemes commonly used in URIs within HTML and similar language (there's work ongoing to come to a common agreement when U is an "about:" URI, for example,  on defining expected behavior when U appears within content which is generated by scripts from a different origin, when the result of a retrieval contains content that looks like it matches a different MIME type than the one it was served with, etc.)

But if M contains a collection of RDF triples and U is used within a triple, there isn't a common widely understood expectation of behavior, at least in terms of processing systems that want use logic processing on the triples retrieved.  This isn't the fault of "U" being badly defined, or the definition of the protocol used if U is accessed as if it were in an a@href, it's a problem in not having a common understanding about M.

If you continue to insist that "U" has a common "meaning" that is independent of the context use, and at the same time insist that the "meaning" of U within a@href in HTML has nothing to do with the "meaning" of U within an <U> <R> <B> triple in RDF, then you are taking an incoherent position.

Persistence and equivalence are two URI relationships that depend on context. Within HTML, a URI is "persistent" insofar as it continues to serve as a good target to illustrate the text that is being marked up. So the persistence of <a href="http://www.w3.org/2001/tag">The W3C TAG</a> depends on the web site containing information about the organization, whether or not the organization is disbanded, split into unter-TAG and uber-TAG, or whether MIT forgets to pay the .org renewal for w3.org.

Note that, for the most part, within that context http://www.w3.org/2001/tag and HtTp:wWw.W3.orG:80/2001/tag  are "equivalent", insofar as their common behavior. 

But within <svg xmlns=" http://www.w3.org/2000/svg">...</svg>, the persistence of utility of http://www.w3.org/2000/svg as namespace name doesn't depend on whether the result of a retrieval on the namespace URI is 200, 303, 404, or timeout. And the URI is *not* equivalent to HtTp:wWw.W3.orG:80/2000/svg. 

I'm very frustrated with this conversation because I think you are spinning in circles, asking nonsensical questions. I've tried time and time again to provide a basis for discussion that I think is rational, but the conversation keeps on slipping back into what I think is nonsense.

The reason why this matters and I keep on trying is that I don't think we can have a sensible architectural discussion about privacy, security, CORS, cross-site-scripting, local storage, publishing and linking, and many of the other topics we should be resolving, if you start with a model of communication using URIs that is decontextualized from the message, the actors involved, the time sequence of events and the roles of the players involved in communication.

 I don't think we can begin to discuss those issues meaningfully using the current AWWW model -- it was a nice try, and maybe a reasonable approximation for some purposes, but it's not good enough to help with most of what we're faced with.

We need to talk about the impact of broken certificate infrastructure, attacks on DNS, the effect of take-down notices and legislatively mandated redirection from acts like SOPA and PIPA, and an model which insists that a URI has an "owner" who is responsible for saying what it's "meaning" is, that model doesn't let us talk about how the web really works.  The fact that AWWW doesn't seem to work resolving some of the more obscure edge cases around linked data and metadata ... it's just more evidence to me that we need to move on.

Larry
--
http://larry.masinter.net

Received on Wednesday, 11 April 2012 10:51:31 UTC