RE: New AFTF draft.

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 Thursday, 12 September 2002 18:29:53 UTC