Hi guys!
> > Not anything concrete yet. I'm still familiarizing myself > with Axis, > > as I've never used it. I'm here because Roy suggested I > drop you guys a > > line. > > Cool! +1. Welcome, Mark. > >>While the reference to the WebMethodFeature does mention > GET, it seems > >>to be light on specifics. Is there some place I should > look for more > >>details? > > > > Hmm, really? That's a concern. Would you mind raising a Last Call > > comment to that effect? > > To be honest, I don't understand the politics and > stakeholders involved > in this discussion. You are part of the wide audience who uses SOAP, and the somewhat smaller audience who builds SOAP implementations. Your impressions as to how developers are using this stuff, and more importantly about how they WANT to use this stuff, are valuable to the XMLP group. The GET discussion came about because there was some concern that the way SOAP was being used in most cases was somehow out of sync with web architecture (Mark was one of the standard-bearers for this idea, in fact). So the stakeholders here include - the current SOAP user community, the SOAP developer community, the W3C TAG, the RESTians, and just about anyone concerned with the future of "Web Services". You're in there. > > The basic idea, which Glen will (hopefully 8-) back me up on, is to > > expose the HTTP method in use to the SOAP developer. If > they specify > > the GET method, and a URI, then they don't need to specify any SOAP > > message, and an HTTP GET happens which may return a SOAP envelope. > > That intent shows through in the spec. However, let me draw your > attention to > > http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#WebMethodFeature > > Specifically, > > > No standard means of representation of arguments or method > names is provided by this specification. Exactly. When you and I discussed this on IRC, Sam, I said two things which I'll reiterate here: 1) If what's in the spec isn't going to be useful, or is going to cause interop nightmares, let's please make a comment or two about it and suggest alternatives. My suggestion was to bring this up on soapbuilders to attempt to get pragmatic points of view as to how implementors hope to deal with this, and how they'd like it to work. 2) For now, simply exposing the switch is enough to get us in line with the spec, and we leave it completely up to the developer to decide how they want to form their URLs - to us it's just a String pointing to an endpoint. --Glen
