Re: New AFTF draft.

No of course not, this is not what I meant to imply; sorry for 
the confusion.

Jean-Jacques.

noah_mendelsohn@us.ibm.com wrote:
> 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 11:23:19 UTC