Re: Attributes should only be there if part of the name/address space

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

Received on Thursday, 20 February 1997 15:32:15 UTC