- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 11 Sep 2002 10:35:11 -0400
- To: "David Orchard" <dorchard@bea.com>
- Cc: "'Carine Bournez'" <carine@w3.org>, "'Christopher B Ferris'" <chrisfer@us.ibm.com>, "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>, "'Herve Ruellan'" <ruellan@crf.canon.fr>, xml-dist-app@w3.org, "'Yves Lafon'" <ylafon@w3.org>
David Orchard writes:
>> The web architecture is pretty clear that resources are
>> hidden by servers.
Right but this is at least potentially a case where the resource is
traveling in the message. There is no server for this resource at the
moment. Its URI typically based on, indeed perhaps explicitly relative
to, a URI that identifies the message itself as the message travels
through space. There is no server. Not all resources live on servers; we
only know that they are accessible, or at least identified by URI, as
these are.
Concrete example; I send you a message that essentially says, "here's my
picture", with attached .jpeg. The jpeg is wrapped up with the message
using DIME, MIME, whatever per the SOAP Attachement feature, and the
Envelope refers to the .jpeg using a CID or similar URI that references
the "part" with the image. So, there's no resource living on a server.
The only embodiment of the picture is in the message. There is a sense in
which the URI is refering to the picture in the abstract as well as to the
JPEG representation; though it's unlikely, one could imagine middleware
that would do the equivalent of content negotiation and offer a .bmp
rendering of the part if asked, all using the same URI.
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!
------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
IBM Corporation Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
"David Orchard" <dorchard@bea.com>
Sent by: xml-dist-app-request@w3.org
09/11/2002 09:44 AM
To: "'Jean-Jacques Moreau'" <moreau@crf.canon.fr>, "'Christopher B Ferris'"
<chrisfer@us.ibm.com>
cc: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>, "'Carine Bournez'"
<carine@w3.org>, "'Herve Ruellan'" <ruellan@crf.canon.fr>,
<xml-dist-app@w3.org>, "'Yves Lafon'" <ylafon@w3.org>, (bcc: Noah
Mendelsohn/Cambridge/IBM)
Subject: RE: New AFTF draft.
Seems to me it should be a representation rather than a resource. Even
though the representation might be identified by a URI (and so be confused
with a Resource). The web architecture is pretty clear that resources are
hidden by servers.
Cheers,
Dave
> -----Original Message-----
> From: xml-dist-app-request@w3.org
> [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Jean-Jacques Moreau
> Sent: Wednesday, September 11, 2002 3:04 AM
> To: Christopher B Ferris
> Cc: Henrik Frystyk Nielsen; Carine Bournez; Herve Ruellan;
> xml-dist-app@w3.org; Yves Lafon
> Subject: Re: New AFTF draft.
>
>
>
> They're not resources, but representations of resources?
> Personally, I think part reads better than resource in this context.
>
> Jean-Jacques.
>
> Christopher B Ferris wrote:
> > Well, there's 'resource' which fits in nicely with the Web
> architecture.
> >
> > e.g.
> > "Compound SOAP structure
> > A compound SOAP structure consists of a primary
> SOAP message part
> > and zero or more related resources."
> >
> > I would even go as far as to add: "identified by a URI".
>
Received on Wednesday, 11 September 2002 10:37:42 UTC