RE: New AFTF draft.

I would be happy to use the term "representation" but I think it takes a
bit more to explain than what Dave proposes.

The traditional Web model is that resolving a URI results in a
representation of the resource identified by that URI. The "resolver"
function is of course late bound and can depend on any number of things.
A "resolution" may involve going to DNS, contacting an HTTP server, etc.
but the only URI involved is that of the resource. The interesting thing
is that there really is no fixed, or even named, concept of a "server". 

When resolution involves an HTTP server, an FTP server, or even a local
file system, we seem to have no problem mapping this model. In the case
of a local file system, the resource is the abstract concept of a named
entity identified by the URI, the actual file is the representation
resulting from the default resolution process.

The reason for picking the local file system example is that it is in
fact very close to what we see in attachments, rather than being a file
system, it is just some other container. However, applying the same Web
model, one has a set of URIs identifying resources for which the actual
bytes included as attachments constitute the representations of these
resources.

That is, we never get in the situation where we have to discuss whether
bags of bytes are resources or representations, they are always
representations.

Henrik 

>I do see both sides to this, but I also think there are some 
>subtleties (I 
>must say, I still think the web architecture is broken in the area of 
>representations.  As I've said before Web arch says:  "everything 
>important is a resource identified by a URI, representations are 
>important, representations are not in all cases resources, 
>representations 
>are not in all cases identified by and distinguished from other 
>representations by distinct URIs."  QED.  Feels wrong.  I 
>think we keep 
>tripping over it, but I probably don't know what I'm talking about. 
>Anyway, I'm not sure the answer on what to call the SOAP attachment is 
>quite so simple thank you!

Received on Wednesday, 11 September 2002 11:20:38 UTC