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

 > Dan Connolly wrote:
 > > It seems very useful to me to say that "objects" (i.e. resources)
 > > are, by definition, identified by their URL.

I don't really like that definition, but I could live with it in a
restricted context.  Seems to me that the result of a resolution is an
object too though it may be a different object from the one referenced
by the URL used in the resolution.  Calling the result by some other
name such as "entity" just adds confusion, in my opinion.  It *is*
useful to know whether you have an identifier for an object, but that
information is separate from the thing itself.  Maybe it is identified
but you don't know what the identifier is yet.  Or maybe it *was*
identified, but that identifier has expired or is no longer supported
by any resolution mechanism.

Saying that an object must be identified is like saying that a value
in a program can not be an object unless the value is referred to by a
symbolic variable.  This is obviously not the case if the value is the
result of an expression and is not yet stored in any variable.

One might counter that a URL is an address, and objects in programs
have addresses too, though they might not have symbolic names.  But
that is not necessarily even true.  Consider Smalltalk where almost
everything is an object (there are a few odd things they left out),
and some objects don't have addresses.

 > > i.e. different URL means, by definition, different object.

That's going too far.  A single object could have multiple URLs, so
different URLs do not necessarily mean different objects.  It may be
an inconvenience (especially for caches), but it is a reality.  The
same rule applies to URNs.

Another claim (sort of an opposite) can be made: if URL-of-A ==
URL-of-B, then A is the same object as B.

 > > 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.

This indirect observation is true even if you have a bunch of bits you
received as the result of a resolution.  How do you know what to do
with the bits?  You are told what type of object it is and what
operations can be applied to it.  You observe what it does via the
operations, though the operations may be applied more immediately and
may be lower level primitives.

 > > 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.

Just as URIs may be used by caches to avoid the traffic altogether?

 > > 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.

Doing that with existing URL schemes is also possible.  The parameters
may be included on an existing http URL, for example, using the
";name=value;name=value" notation, or augmenting the parameters that
are already there just as Tim B.L. described.

 > > 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.

This is fine with me too.  But just as there is value in
specifying the URL of a document relative to a base URL,
it may be useful to specify H' relative to H.  An information
provider need not do that, of course, just as they need not
use relative URLs.

Larry Masinter writes:
 > If we wanted ETags to be "names", we would have given them more
 > global scope.

So an ETag is a kind of local URN that must be resolved relative to
the known server?

 > 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?

If we can agree on all of this, I would certainly help document it.


Received on Thursday, 20 February 1997 17:30:50 UTC