Re: Meaning of names and operations of services

Larry Masinter writes:

> In general, it is a bad idea to design a language where the
> meaning of a term in the language depends on the operational
> behavior of a service.

I can't tell if we agree or disagree, or perhaps in some ways both. 
Regarding the above: wes, indeed, but I would go further.  What you say of 
languages in general is most especially true of the Web.  I think the 
reasons are well explored in the TAG's Self-Describing Web finding, which 
is in near final draft form at [1], and which should be published 
officially within a few days (in the interest of full disclosure, I am the 
editor of that Finding.)

In short, the Web has as one if its particular goals that ad hoc 
exploration be possible.  The characteristic that you discourage for 
languages in general is particularly harmful for the Web, I think.  The 
whole point is that, with the Web, I should be able to stumble on a URI 
wherever I might find it (e.g. doing a Google search), poke at it with a 
standard operation such as HTTP GET  and in the main path case discover 
from that representations of the resource.  As the finding describes [2], 
I should be able to discover the correct interpretation of what I find by 
application of specifications that are discoverable, recursively, from 
references from the URI specification itself.

So, this indirectly explains why having the same URI identify both a 
resource and its description is bad.

As you say above, having the meaning of a URI depend on context or 
operational details of some conflicts with this characteristic of the Web, 
I think, with the very particular exception that anyone running a Web 
server is obligated to serve faithful representations of a resource 
(faithful is my term), if representations are served at all.  Still, that 
does not make the meaning of the URI depend on operation of the service: 
the right way to think about it is that the assignment authority 
associates the URI with a resource.  The Web server is then obligated to 
serve representations faithfully, if it serves at all. 

So, while I agree with the quote from you as far as it goes, you imply 
that what IANA chooses to do is therefore of low importance.  On that I 
respectfully disagree.  The question, I think, is not whether they are 
running some random service, but in particular a Web server that will 
respond to HTTP GETs for the URIs identifying certain abstractions.  While 
the meaning of those URIs does not "depend" on what the server does, it is 
very important that the URI refer to one thing and not more, it's 
desirable that representations be available if the resource is an 
information resource or that a URI with descriptions be available 
(presumably through redirection) if not, and that any representations 
returned be faithful to the underlying resource.

Whether the particular solution proposed in resolving httpRange-14 is the 
best one is hard to say.  Whether it's practical to deploy seems to be the 
subject of ongoing debate in various communities.  Still, I agree with Tim 
that the costs of reopening the decision would be very high at this point. 
 So, I think we should at least try hard to make it work.  As to returning 
404's, that is equally antithetical to the Self-Describing Web, in that it 
becomes hard to find out information about resources in a standardized 
way.  Mark Nottingham wrote yeterday [3] that:  "consensus was already 
moving in the direction of NOT having the registered relations be 
URIs...That means  that, to some degree, this discussion is moot."  Seems 
so, though of course using anything other than URIs for identity raises 
its own concerns Web-wise.

Also, as an aside, in a member-only email [4] you asked some questions 
about what the goals of the new Self-Describing Web finding might be;  the 
answer is, in part IMO, to contribute to discussions like this.  Thank 
you.

Noah

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[2] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html#grounding
[3] http://lists.w3.org/Archives/Public/www-tag/2009Jan/0136.html
[4] http://lists.w3.org/Archives/Member/tag/2009Jan/0064.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@adobe.com>
Sent by: www-tag-request@w3.org
01/30/2009 09:38 AM
 
        To:     "www-tag@w3.org WG" <www-tag@w3.org>
        cc:     Lisa Dusseault <lisa@osafoundation.org>, Mark Nottingham 
<mnot@mnot.net>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Meaning of names and operations of services



In general, it is a bad idea to design a language where the
meaning of a term in the language depends on the operational
behavior of a service.

Generally, this is because the meaning of the language terms
needs to be longer-lived and more stable than any particular
service or service guarantee, and thus independent of any
particular service.

The meaning of "describedBy" is term in a link relation language.
The IANA web site is a service.

It is a bad idea for the meaning of "describedBy" to depend on
the long-term operational behavior of the IANA web site.

In some cases, a term in a language actually makes reference to
the operational behavior of a service.

"http://www.iana.org/blargh" is a term in the URI language which
identifies the operational behavior of the "www.iana.org" HTTP
service for the "/blargh" path. Other languages which include the
URI language may then give derivative meanings to the term.
However, in a language where the meaning of "blargh" depends on
the operational behavior of "www.iana.org" has given it a
transient meaning.

It is a *good* idea (best practice) to run services which help
people discover the meaning of terms they haven't seen before.
Discovery of meaning is hard. Such services are useful, but they
aren't definitional. They aid but do not determine.

The IANA registry is a registration service. The IANA web site is
a courtesy. IANA makes information from the IANA registry
available on the IANA web site, but the IANA web site is not the
registry, it is merely a service run by them to make their
registry available.

I think attempts to get IANA to change the operational behavior
of the IANA web site because it might have some effect on the
meaning of terms in the "Link" relationship language is a sign
that some architectural error has been made.

I don't think the problem is so much with "httpRange" as it is in
languages that assume that "best practice" is always followed and
that web sites that exist today will exist forever. Do not put
operational "best practice" as a requirement for having
well-defined semantically coherent languages.

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

Received on Friday, 30 January 2009 15:14:23 UTC