Re: New AFTF draft.

Jean-Jacques Moreau writes:

>> My assumption so far was that the SOAP processor 
>> and the "packaging module" would be one and the 
>> same thing, i.e. an extended SOAP processor; 
>> but I agree they could indeed be kept 
>> separate.

Let's keep in mind that SOAP does not discuss implementations.  It 
presents wire formats and describes their interpretation, in this case as 
a primary envelope with linked non-envelope parts.  How code is 
structured, combined, etc. is beyond the scope of our specifications.  The 
term node is therefore a catchall for that block box that you build that 
receives or sends SOAP messages.  How you structure it is up to you, and 
may be different from the way I do it.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Jean-Jacques Moreau" <moreau@crf.canon.fr>
Sent by: xml-dist-app-request@w3.org
09/13/02 06:54 AM

 
        To:     "John J. Barton" <John_Barton@hpl.hp.com>
        cc:     David Orchard <dorchard@bea.com>, "'Christopher B Ferris'" 
<chrisfer@us.ibm.com>, "'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.


Interesting perspective. I think what you call a SOAP module is 
what we call a SOAP processor; SOAP 1.2 defines a module as the 
SOAP header block implementing a given SOAP feature (e.g. 
authentication). My assumption so far was that the SOAP processor 
and the "packaging module" would be one and the same thing, i.e. 
an extended SOAP processor; but I agree they could indeed be kept 
separate.

Jean-Jacques.

John J. Barton wrote:
> I'm sorry that I was not clear.  Let me try again.
> 
> If we describe the package, then we have no problems.
> We have some bytes in some formats and we simply
> give the rules for those formats.
> 
> But what is being attempted in AFTF is to describe the
> relation between a SOAP message and attachments
> without describing the package.  Naturally this description
> starts with the SOAP message and proceeds to the URI
> that names an attachment.  Here is where the trouble
> begins.  A URI names a Resource.  We know
> that, in this particular example, resolving this resource
> will give a copy of the bits in the attachment. After all
> we made the example up.  But, in general, the
> SOAP module processing the message does NOT know
> that any particular URI will give a copy of the bits in an
> attachment.  That flexibility is why we used a URI.
> So the SOAP module (and hence the SOAP message)
> knows the attachment only as a resource.  It has an
> interface "GET URI" and just in this case the implementation
> is an attachment.
> 
> That is what I meant by "From the perspective of the SOAP
> module the attachments are resources."  It only has URIs.
> 
> In processing the SOAP message we eventually have to
> resolve GET URI into some bits.  I called that place in the
> process the packaging module.  The resolution of the URI
> sucks up the bits of the attachment and passes them to
> the SOAP module: then we have a representation of the
> resource.
> 
> That is what I meant by "From the perspective of the packaging
> module the attachments are representations."
> 
> In both cases the key phrase is "from the perspective".  Both
> "resource" and "representation" are about roles or views of
> bits.  Resources are abstractions of bits; representations are
> reification of those abstractions.  Neither are the bits.
> 
> I don't think that equating attachments to representations
> will be helpful in the long run for exactly the reasons that
> we cannot equate bits of a database or file system to representations
> in the Web today.  Attachments, like database entries, are just
> bits to be interpreted by a URI scheme processor to produce a
> representation.  A few primitive scheme processors will simply
> copy bits: that's what "file:" does and often what "http:" does.
> There are lots of alternatives in the web today and soon they
> will be applied to SOAP messages as well.
> 
> If I attach a perl program is it a representation?  If I attach
> a database?  an exe? How about a complete file system?
> If it has to be interpreted to become a representation then
> how can it be a representation?
> 
> John.
> 
> At 08:14 PM 9/11/2002 -0700, David Orchard wrote:
> 
>> I think I disagree that attachments are resources from the soap module
>> perspective.  Regardless of the packaging or boxcarring mechanism, 
>> they are
>> representations in flight.  URI usage does not mean that attachments 
are
>> resources.
>>
>> Cheers,
>> Dave
>>
>> > -----Original Message-----
>> > From: John J. Barton [mailto:John_Barton@hpl.hp.com]
>> > Sent: Wednesday, September 11, 2002 8:43 AM
>> > To: David Orchard; 'Jean-Jacques Moreau'; 'Christopher B Ferris'
>> > Cc: 'Henrik Frystyk Nielsen'; 'Carine Bournez'; 'Herve Ruellan';
>> > xml-dist-app@w3.org; 'Yves Lafon'
>> > Subject: RE: New AFTF draft.
>> >
>> >
>> >  From the perspective of the SOAP module the attachments are
>> > resources.  That is why we use URIs to name them.
>> >
>> >  From the perspective of the packaging module the attachments
>> > are representations.  It deals with bytes.
>> >
>> > The confusing concept from the Web point of view is "Compound
>> > SOAP structure".  This programming construct cannot be
>> > precisely defined: it may contain pointers that are not bound.  A
>> > compound SOAP structure is a logically a "view" rather than a
>> > physical region of memory or a packet of data.  The construct
>> > that can be defined is the message package.  That is why writing
>> > the spec for the package is easier that defining how the package
>> > looks from the SOAP layer.
>> >
>> > John.
>> >
>> > At 06:44 AM 9/11/2002 -0700, David Orchard wrote:
>> >
>> > >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".
>> > > >
>> >
>> > ______________________________________________________
>> > 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
>> >
>> >
> 
> 
> ______________________________________________________
> 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 Friday, 13 September 2002 10:11:48 UTC