RE: Proposed text for 2.2.21 (take 2)

Just to summarise what people have said about the proposed text and my
responses: 

1. The first is whether parameters in a URL are message content. Let's
consider a few cases for the all well-known getStock example (getting a
stock quote for the last 10 days):

case 1:
GET  http://www.stockquote.com/stock/companyX/slidingWindow/10

case 2:
GET http://www.stockquote.com/stock?company=companyX&slidingWindow=10

It appears to me that case 1 has no content. In the second case, however,
the parameters appear to be the content since only
http://www.stockquote.com/stock is regarded as the URI. 

2. The second is whether to include the plain XML over HTTP example. If I
recall correctly, the main objection is that plain XML over HTTP does not
supported extended functionality defined in this architecture.  This is fine
since I made this point clear in the text.  IMHO, I really think we should
include this because: a) Many people are doing this already.  Supporting
this pattern can only make this architecture more useful. b) Technically,
using SOAP is not justified if extended functionality is not needed or when
performance is critical. 

Hao 

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Saturday, June 28, 2003 7:27 AM
To: 'Ugo Corda'; 'Anne Thomas Manes'; 'Francis McCabe'; Hao He
Cc: www-ws-arch@w3.org
Subject: RE: Proposed text for 2.2.21 (take 2)


Indeed.  I had tried a while ago to rationalize the relationship between
SOAP message and representations.  I think we need to be clear that a SOAP
message *may* contain a representation, but it is not a "a SOAP message is-a
type of representation".  The features and bindings section describes the
properties of soap messages and the shared environment.  Representations are
part of the properties of the message.  Other properties include binding
specific properties that aren't in the representation.

It should be observed that the soap+xml mime type is for envelope infosets
serialized as xml.  Now I *think* that representation=envelope infoset.
Might be interesting to call this out.

messages, envelopes, representations, meps.  Good stuff to get clear.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Ugo Corda
> Sent: Friday, June 27, 2003 10:47 AM
> To: Anne Thomas Manes; Francis McCabe; Hao He
> Cc: www-ws-arch@w3.org
> Subject: RE: Proposed text for 2.2.21 (take 2)
> 
> 
> 
> Well, according to the SOAP definition of a Response MEP 
> (which the HTTP GET binding is associated with):
> "The SOAP Response MEP defines a pattern for the exchange of 
> a non-SOAP message acting as a request followed by a SOAP 
> message acting as a response".
> 
> So the SOAP 1.2 spec says there are two messages involved ...
> 
> Ugo
> 
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Friday, June 27, 2003 10:29 AM
> > To: Ugo Corda; Francis McCabe; Hao He
> > Cc: www-ws-arch@w3.org
> > Subject: Re: Proposed text for 2.2.21 (take 2)
> > 
> > 
> > I think Mark's point is that when you use the HTTP GET Web 
> > Feature, you
> > don't *send* a message to the resource. You simply GET the 
> > representation,
> > which happens to be a SOAP message.
> > 
> > Anne
> > 
> > ----- Original Message -----
> > From: "Ugo Corda" <UCorda@SeeBeyond.com>
> > To: "Francis McCabe" <fgm@fla.fujitsu.com>; "Hao He" 
> > <Hao.He@thomson.com.au>
> > Cc: <www-ws-arch@w3.org>
> > Sent: Friday, June 27, 2003 12:50 PM
> > Subject: RE: Proposed text for 2.2.21 (take 2)
> > 
> > 
> > >
> > > > I would strongly suggest removing the references to using 
> > HTTP GET as a
> > > > way of sending messages. Mark B is right on this one. If 
> > you want to
> > > > use HTTP, the appropriate verb is POST.
> > >
> > > I don't fully understand your comment. I think Hao was 
> > referring to the
> > Web Method feature of SOAP 1.2. According to that feature, 
> an HTTP GET
> > represents a particular binding of a SOAP Response MEP. So an 
> > HTTP GET used
> > in this context is a legitimate realization of the type of 
> messages we
> > address in this spec.
> > >
> > > > I suggest further that the plain XML reference is not one 
> > that has been
> > > > endorsed by the group. Indeed I recall significant 
> > pushback on this
> > one...
> > >
> > > I agree.
> > >
> > > Ugo
> > >
> > >
> > 
> > 
> 
>