Re: Attributes should only be there if part of the name/address space
Larry Masinter <masinter@parc.xerox.com> Thu, 20 February 1997 21:09 UTC
Received: from cnri by ietf.org id aa26951; 20 Feb 97 16:09 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa22065; 20 Feb 97 16:08 EST
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id PAA11459 for uri-out; Thu, 20 Feb 1997 15:32:15 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id PAA11454 for <uri@services.bunyip.com>; Thu, 20 Feb 1997 15:32:10 -0500 (EST)
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26218 (mail destined for uri@services.bunyip.com); Thu, 20 Feb 97 15:31:35 -0500
Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16513(2)>; Thu, 20 Feb 1997 12:30:51 PST
Received: from palimpsest ([127.0.0.1]) by palimpsest.parc.xerox.com with SMTP id <242>; Thu, 20 Feb 1997 12:30:35 PDT
Message-Id: <330CB46B.FA8@parc.xerox.com>
Date: Thu, 20 Feb 1997 11:30:35 -0800
From: Larry Masinter <masinter@parc.xerox.com>
Organization: Xerox PARC
X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u)
Mime-Version: 1.0
To: Dan Connolly <connolly@w3.org>
Cc: Daniel LaLiberte <liberte@ncsa.uiuc.edu>, Tim Berners-Lee <timbl@w3.org>, Erik Guttman <eguttman@ns.incog.com>, uri@bunyip.com
Subject: Re: Attributes should only be there if part of the name/address space
References: <3.0.32.19970218151607.0080d4d0@hq.lcs.mit.edu> <199702201524.JAA11237@void.ncsa.uiuc.edu> <330C7650.6EF22561@w3.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-uri@bunyip.com
Precedence: bulk
Dan Connolly wrote: > > Daniel LaLiberte wrote: > > > > Tim Berners-Lee writes: > > > under no circumstances should any > > > information other than those needed to identify an object be > > > included in the URL. If the information *is* needed to identify > > > the object, then it must (clearly) be included in the URL. > > > > This is a good policy, but I want to clarify something. The question > > is, what is the "object" that is identified? > > It seems very useful to me to say that "objects" (i.e. resources) > are, by definition, identified by their URL. > > i.e. different URL means, by definition, different object. > > In this case, an object isn't directly observable: the only > way to observe it is to send it messages and see what comes > back. > > See: http://www.w3.org/pub/WWW/Architecture/Terms#resource > > I might restate Tim's distinction between 'information needed > to identify an object' and other sorts of information in terms > of 6th grade grammar: restrictive and non-restrictive clauses. > > If you're talking about "the document XYZ, which has title > ABC" then then ABC must not be part of the identifier. Because > you might want a reference ala "the document XYZ, which > has author Fred" to be recognized as the same resource. > > On the other hand, you might refer to a resource using > a restrictive clause: "the service ZZZ that started in 1996". > In this case, "the service ZZZ that started in 1995" is a > distinct resource. So the year is part of the URL. I like this analysis, and would welcome some suggested wording for how we might get this captured in draft-masinter-url-process Internet Draft. Suggestions to ietf-url@imc.org. While you might imagine we could add it to the "generic syntax" draft (draft-fielding-url-syntax), I think that we're really in the area of future philosphy rather than present reality. > > Now, it is possible to identify the collection with one identifier and > > also identify each of the individual members of the collection with > > their own independent identifiers. HTTP 1.1 provides a different > > alternative, that of entity tags for identifying individual members of > > a collection all identified by a single http URL. > > I don't consider that etags refer to different resources: they refer > to entities in responses from resources. They're used to predict > how a resource will respond to a message, so that you can avoid > the traffic altogether. > > > My suggestion is that it is desirable to have a uniform format for > > the complete identification of an object, including all the parameters > > that were used. It may not always be possible to create or provide > > such an identifier, but when it is, it is useful. > > Hmmm... I suppose so. That is, given any http resource H, you > can define another resource, H', where sending messages to H' > is defined as sending messages to H with certain parameters > bound to certain values. > > Doing that with a new URL scheme is possible. > > But let me suggest another possibility: rather than > computing the address of H' from the address of H and > the parameters, we leave the information provider to > choose any address at all for H', and provide external > metainfo that allows clients to discern the relationship. > > For example, suppose you want "the resource http://www.w3.org/ > where accept-lanugage is fr". Hmmm... the strategy I'm > describing doesn't allow you to express exactly that. Rather, > it allows you to express "a resource that is a french > variant of http://www.w3.org": > > <about href="http://www.w3.org/index.fr"> > <link href="http://www.w3.org/" rel=language-variant> > <meta name="content-language" content="fr"> > </about> > > Dan We went around on this many times in HTTP-WG. In the end, it was: the resource provider gets to decide what the granularity of "resource" is. If the resource provider wants you to be able to name "the resource http://www.w3.org/ where accept-language is fr" then the resource provider should give it a name. If we wanted ETags to be "names", we would have given them more global scope. This was also a lengthy debate in the working group; in the end, we just needed a protocol element with local scope, and increasing the scope of it (e.g., by using content-IDs as ETags) just got in the way. I'm not sure if this belongs in the URL document. It _is_ a discussion that seems to be repeated if not recorded, but I'm not sure where or in which document it would fit. Suggestions? Thanks, Larry
- Attributes should only be there if part of the na… Tim Berners-Lee
- Attributes should only be there if part of the na… Daniel LaLiberte
- Re: Attributes should only be there if part of th… Dan Connolly
- Re: Attributes should only be there if part of th… Larry Masinter
- Re: Attributes should only be there if part of th… Daniel LaLiberte
- Re: Attributes should only be there if part of th… Dan Connolly
- Re: Attributes should only be there if part of th… Larry Masinter
- Re: Attributes should only be there if part of th… Dan Connolly
- Re: Resources and Identifiers Dan Connolly
- Re: Resources and Identifiers Michael Mealling
- Resources and Identifiers Daniel LaLiberte
- Re: Resources and Identifiers Daniel LaLiberte