Hey. On Sun, Jun 30, 2002 at 11:12:57PM -0400, Sam Ruby wrote: > > 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.
Ah, nevermind that! Just send a quick note to [EMAIL PROTECTED] saying "I read that section and don't understand what it means to implement it." (if that's what you meant). That's it! I'd be happy to submit it on your behalf if you don't want to have to bother with it. Let me know. This is serious stuff. *You* are our target audience, and if it's not obvious what the spec is asking of you, that's a major problem that we need to resolve before going to Rec. > > 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. 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. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. [EMAIL PROTECTED] http://www.markbaker.ca http://www.idokorro.com
