- 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