Web method values as QNames (was Re: FW: LC Comments: Web Method Feature

On Mon, Jul 15, 2002 at 11:10:23AM -0400, rubys@us.ibm.com wrote:
> I was quite willing to explore it, but I don't believe that we came to
> agreement.  The setOperationName [3] method accepts a namespace qualified
> name as an argument.  If there was a standard QName defined for this
> concept in the SOAP specification, then I would certainly see to it that
> Axis support it.  Whenever we got around to that part of the discussion,
> you seemed to acknowledge that a QName was required in almost a Sinefeldian
> "not that there is anything wrong with that". [4] [5] [6]

Yup.  8-)

For HTTP, the QName URI won't go over the wire, so that's why I didn't
think it was important to standardize on a URI at this point.

But if other SOAP libraries are going to have the same issue as Axis -
that they need a URI to QName-ize the HTTP method - then having a
standardized one would probably help in these ways;

- now, so that there's some consistency when writing code for different
libraries
- in the future, when the URI does go over the wire over some new
protocol or HTTP extension (like PEP's PEP method)

But anyhow, for the purposes of the thread that you responded to, I was
just pointing out that choosing a method by default was inconsistent
with how Axis (and presumably all other SOAP libs) work.

I think we should record this (Web methods as QNames) as an issue.  My
proposal would be to make webmeth:method a QName, and create a URI (or
use http://www.ietf.org/rfc/rfc2616.txt - not sure of the cons of doing
that) to be used for denoting the methods defined in RFC 2616.
Depending upon the choice of URI, we may want to say something about
WebDAV too.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Monday, 15 July 2002 12:48:19 UTC