- From: Doug Bunting <db134722@iplanet.com>
- Date: Mon, 04 Nov 2002 16:38:07 -0800
- To: David Booth <dbooth@w3.org>, "'Hugo Haas'" <hugo@w3.org>
- Cc: www-ws-arch@w3.org
- Message-id: <3DC712EF.4050506@iPlanet.com>
David and Hugo,
I also concur with Chris and David.
What is the procedure we need to follow when providing additional
feedback on an unsatisfactory closure of a last call issue?
thanx,
doug
David Orchard wrote:
> I totally concur with ChrisF. And this fictional URIResolver is
> exactly what we were thinking of how the issue of references would be
> dealt with.
>
> Cheers,
> Dave
>
> -----Original Message-----
> From: www-ws-arch-request@w3.org
> [mailto:www-ws-arch-request@w3.org]On Behalf Of Christopher B Ferris
> Sent: Wednesday, October 30, 2002 9:42 AM
> To: Hugo Haas
> Cc: www-ws-arch@w3.org
> Subject: Re: SOAP AF review comment 1 response
>
>
> I'm not overly thrilled with this response, particularly the
> second part.
>
> I think that it all boils down to perspective. If you look at a
> message that is
> either multipart/related, or application/dime from the outside,
> then clearly,
> there is a different semantic from dereferencing a URI to retrieve
> a resource
> representation and simply selecting a MIME part or DIME record and
> streaming
> its contents.
>
> However, if you look at it from the inside (from the perspective
> of processing
> the SOAP message) you stumble across a URI references and you
> dereference
> it to retrieve a representation of the resource identified by that
> URI. Whether it
> just happened to be "local" (e.g. packaged with the SOAP message in a
> multipart/related or application/dime encapsulation) or whether it
> was actually
> retrieved from the Web, is (or at least I claim it SHOULD be)
> irrelevant.
>
> IMO, a valid use case not considered in the intro to the
> SOAP1.2-AF spec
> is where I have an XML document containing URI references to
> resources that
> are behind my firewall. If the message is sent outside my
> firewall, the resources
> that these URIs identify become inaccessible. Hence, a valid
> approach to solving
> this problem would be to retrieve the representations and "cache"
> them with the
> message that references them. Thus, when the processer that
> receives the message
> processes that message it can establish a URIResolver with the
> MIME or DIME
> package as its context. This URIResolver is interposed on any
> requests to dereference
> a URI. If the URI is contained in the MIME or DIME package, then
> the part/record that
> has that URI as its identifier is returned, otherwise, the request
> is dispatched to the
> Web. In either case, the result is the same. The "application"
> doesn't know the difference.
> It just dereferenced the URI and retrieved a representation of the
> identified resource.
>
> The same application behind the firewall might not have the
> representation packaged
> with the SOAP message, but its processing is identical.
>
> Cheers,
>
> Christopher Ferris
> Architect, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
> Hugo Haas wrote on 10/30/2002 11:42:31 AM:
>
> > All,
> >
> > Attached is the answer of the XML Protocol Working Group to our SOAP
> > Attachment Feature review comment 1[1].
> >
> > Regards,
> >
> > Hugo
> >
> > 1. http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390
> > --
> > Hugo Haas - W3C
> > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/
> >
> > ----- Message from Carine Bournez <carine@w3.org> on Wed, 30 Oct
> 2002 17:22:35 +0100 -----
> >
> > To:
> >
> > hugo@w3.org
> >
> > cc:
> >
> > xmlp-comments@w3.org
> >
> > Subject:
> >
> > Closing issue 390
> >
> >
> > Hugo,
> >
> > You raised issue 390 [0] on behalf of WSA WG.
> >
> > The first part of the issue is a general request to explain why and
> > when using the attachments (rather than links to resources):
> > " We recommend the XML Protocol Working Group
> > to document the motivations for using the SOAP Attachment
> Feature,
> > for example with a set of usage scenarios."
> >
> > In AF's doc introduction [1], the 3 bullets give use cases of
> attachments
> > from a SOAP point of view. An attachment is a particular part of the
> > SOAP message. We don't see any further need to give use cases of
> attachment
> > along with some particular implementations and particular bindings.
> > The attachment feature was designed initially to complete the SOAP
> > specification.
> >
> > The second part of the issue asks clarifications about how resources
> > on the web (referenced by a URI) are added as a part (how a
> change of
> > reference is handled):
> > " For example, a
> > reference in a SOAP element might be
> <http://example.com/Sound.wav>.
> > My SOAP application now uses some SOAP attachment feature,
> perhaps
> > MIME. The representation is now identified by
> > <cid:someidentifierforSoundwav>. "
> >
> > We claim that the semantics is not the same when you refer to an
> external
> > URI than when you attach a particular representation of that
> resource (a
> > snapshot). We allow both external and internal reference to
>
> > a resource, which are different usages, but we do not preclude any.
> >
> > Wrt referencing attachment in general, it is a binding problem
> and not
> > an attachment feature issue. It is possible to refer either to
> external
> > URIs, either to parts of the secondary bag. The way the URI is
> resolved
> > is certainly not in scope of the Attachment feature.
> >
> >
> > Please let us know asap if this is not satisfactory.
> >
> >
> > [0] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x390
> > [1] http://www.w3.org/TR/2002/WD-soap12-af-20020814/#intro
> >
> >
> > --
> > Carine Bournez -+- W3C / INRIA Sophia-Antipolis
>
Received on Monday, 4 November 2002 19:40:28 UTC