W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

FW: Issue 189 proposals:

From: David Orchard <dorchard@bea.com>
Date: Thu, 29 Jul 2004 08:39:07 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF093E9728@ussjex01.amer.bea.com>
To: <www-ws-desc@w3.org>



> -----Original Message-----
> From: David Orchard
> Sent: Thursday, July 29, 2004 8:37 AM
> To: 'Hugo Haas'
> Subject: RE: Issue 189 proposals:
> 
> 
> 
> > -----Original Message-----
> > From: Hugo Haas [mailto:hugo@w3.org]
> > Sent: Wednesday, July 28, 2004 12:44 AM
> > To: David Orchard
> > Cc: www-ws-desc@w3.org
> > Subject: Re: Issue 189 proposals:
> >
> > Hi Dave.
> >
> > I am afraid that your answer didn't completely clear up my
confusion.
> >
> > * David Orchard <dorchard@bea.com> [2004-07-26 14:44-0700]
> > > Hugo has already found his answer, which hopefully is that the
rest of
> > > the xml is not serialized at all.
> >
> > Here, you are saying that the rest of the XML is not serialized at
all
> > - in the message body, I presume.
> >
> > * David Orchard <dorchard@bea.com> [2004-07-27 11:48-0700]
> > > The 2 cases where part of the data that is in the body may also
need
> to
> > > go into the URI, but the entire element should be serialized, are
PUT
> > > and POST, where there is a body and serialization into the URI.
The
> > > point is that there are 2 aspects of serialization for these: the
> > > serialization into the body and into the URI.
> > >
> > > GET and DELETE have only a serialization into the URI, but they
can
> also
> > > do with truncating the instance data.  In this case, then the same
> type
> > > could be used for GET/PUT/POST/DELETE operations.
> > >
> > > Imagine where there is an Artist with an ID element, and the ID
> element
> > > is the unique identifier (and damn it, we should allow attributes
for
> > > this case!!).
> > > <Artist><ArtistID>5</ArtistID><stuff/></Artist>
> > >
> > > I may want to PUT a new artist using ArtistID 5, ie PUT /Artist/5.
> This
> > > is something like location="/Artist/{ArtistID/}.  Same holds true
for
> > > POST, where the client could be suggesting that /Artist/5 is the
URI
> for
> > > the new artist.  The body of these would be the entire Artist
element.
> >
> > And here you are saying that the message body is the entire Artist
> > element, which I understand to mean that the rest of the XML is
being
> > serialized.
> 
> The entire Artist element would in be the POST. And you did it right
in
> the example.
> 
> >
> > The second version makes sense to me, otherwise we would lose
> > information. So this is the one I have implemented. Please check:
> >
> >     3.8.1.2 Case elements NOT cited in whttp:location attribute
> >     http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> > bindings.html?rev=1.58&content-type=text/html;%20charset=utf-
> > 8#_http_operation_location_notcited_get
> >
> > and:
> >
> >     3.8.1.2.2 Serialization in the message body
> >     http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> > bindings.html?rev=1.58&content-type=text/html;%20charset=utf-8
> >
> > If I still got it wrong, can you please send me a diff or an updated
> > XMLspec version of Part 3?
> 
> I wouldn't have done it this way, but it's good enough as written.
> 
> I probably would have done
> 
> If an element name appears in the whttp:location attribute information
> item not followed by a slash, then the elements not cited must be
> serialized as parameters in the request URI (see 3.8.1.2.1
Serialization
> in the request URI).  Note that instance data will be serialized in
the
> message body (see 3.8.1.2.2 Serialization in the message body), in the
> case of an element followed by a slash.
> 
> But they mean the same thing.
> 
> Cheers,
> Dave
Received on Thursday, 29 July 2004 11:39:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT