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

[Dan Connolly <[e-mail]>]

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.


> 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