RE: New AFTF draft.

At 08:22 PM 9/11/2002 -0700, David Orchard wrote:
>...
>
>However we express it, I do think we agree about the use of
>representation for attachments, which is the real point of this.

To me the meaning of representation and resource are fundamentally
connected: a "resource" is a abstraction identified by a URI and a
"representation" is the concrete set of bits one obtains from operating
GET on a URI.  Where trouble starts is when we try to run this definition
backwards: every concrete set of bits is not a representation.

Files, database entries, and attachments are all sets of bits.
Attachments have the same standing as the data in a filesystem or a
database behind a server.  When these bits are copied out in response
to a GET they become part of a representation.  Before that they are not
defined in the Web world: they just are neither resources nor representations.

Yes things get a bit fuzzy when we talk about so called local files, but
I think the definitions of resource and representation still hold.  The bits
on the disk drive are outside of the world of resources and representations.
The act of pulling bits named by a URI off the disk causes them to be
(part of) a representation.

Unfortunately for our little brains,  in the most important but "trivial" 
case, the
representation for a resource is bitwise identical with a file.  That is 
the case
for most early Web content: a file was copied out in response to a GET.
In the next most complex case, a server can choose one of several files to
copy out in response to a GET.  It is at this point that we start trying to 
call
these files different "representations" of a "resource".  But we have to
stick to our logic and insist that representations only result from 
dereferencing
a URI.

I will just reiterate that the source of the quandary here is the attempt to
define an implementation -- the nature of attachments -- from the point of
view of an entity -- the SOAP module -- that can, by your own construction,
know only the interface -- the URI.  You just cannot get there from here.
The best you can hope for is to enumerate some example implementations
then disavow their details.

John.

> > -----Original Message-----
> > From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> > Sent: Wednesday, September 11, 2002 8:20 AM
> > To: noah_mendelsohn@us.ibm.com; David Orchard
> > Cc: Carine Bournez; Christopher B Ferris; Jean-Jacques Moreau; Herve
> > Ruellan; xml-dist-app@w3.org; Yves Lafon
> > Subject: 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!
> >

______________________________________________________
John J. Barton          email:  John_Barton@hpl.hp.com
http://www.hpl.hp.com/personal/John_Barton/index.htm
MS 1U-17  Hewlett-Packard Labs
1501 Page Mill Road              phone: (650)-236-2888
Palo Alto CA  94304-1126         FAX:   (650)-857-5100

Received on Thursday, 12 September 2002 11:20:59 UTC