- From: David Orchard <dorchard@bea.com>
- Date: Thu, 29 Jul 2004 08:39:07 -0700
- 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 UTC