Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Message-ID: <3D1FE367.2070807@apache.org>
Date: Mon, 01 Jul 2002 01:06:47 -0400
From: Sam Ruby <rubys@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: axis-dev@xml.apache.org
Subject: Re: SOAP 1.2, GET, and Axis
References: <20020630225958.K3560@www.markbaker.ca>
 <3D1FC8B9.4010803@apache.org> <20020630235215.A10550@www.markbaker.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mark Baker wrote:
 >
 >> No standard means of representation of arguments or method names is
 >> provided by this specification.
 >
 > Does that matter?
 >
 > From the client POV, the developer provides the URI via
 > Call.setTargetEndpointAddress(). GET is invoked directly on that, the
 > same way it would be if you typed that URI into a browser.
 >
 > From the server/service POV, I don't see that it makes a difference
 > either.

For all idempotent and side effect free methods with zero arguments, sure.

The value of REST is that it provides a Simple Access Protocol to 
Objects which it refers to as Resources.  From a REST and HTTP point of 
view, URIs are opaque.

The value of SOAP is that it provides a REpresentation suitable for the 
Transfer of States.  SOAP 1.2 Part I Section 5 defines the infoset for 
the state to be transferred which it refers to as a SOAP message.  The 
concern I have is that there is no representation provided for bindings 
of such infosets on the sending side when desired web method to be used 
is HTTP GET.

What is needed, in my mind, is something analogous to 
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1 .  Can you 
imagine how much less useful HTML FORMS would be if there was no 
standard means of representation of control name/control value pairs 
provided by the HTML specification?  And if each browser and server 
application were free to define their own?

Section 4.1.1 of the SOAP 1.2 spec implies that such is out of scope for 
the SOAP specifications, and hints to WSDL as the appropriate place.  I 
can certainly accept this, but lets go full circle and reexamine your 
first post to this mailing list:

> I've had a look through the archives, and haven't found any discussion
> about what the Axis team is thinking about doing to support the
> "Web Method Specification Feature"[1] of SOAP 1.2 when bound to HTTP.
> I'm specifically interested in GET support.

Perhaps we should be looking to the Web Services Description Working 
Group to provide more details first?

Thanks for listening.

- Sam Ruby