W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

Re: Revised proposed Issue 54 resolution

From: Mark Baker <distobj@acm.org>
Date: Thu, 22 Apr 2004 16:50:29 -0400
To: www-ws-desc@w3.org
Message-ID: <20040422205029.GA3347@markbaker.ca>

Well, I suppose that would work, but it's a rather non-scalable
form of extension, no?  A new operation definition per i/o
media type pair?  Eeek. 8-)

Could this be done on the wsdl:{input,output} elements?

    <wsdl:interface name="foo">
        <wsdl:operation name="getFoo">
            <wsdl:input element="schema1" type="application/xhtml+xml"/>
            <wsdl:output element="schema2" type="application/svg+xml"/>
        </wsdl:operation>
    </wsdl:interface>

Actually, come to think of it, wsdl:{input,output} should be able
to do that anyhow independent of this issue; the schema alone is
insufficient information to identify the intended semantics of the
representation.  Consider one of those funky XSLT style sheets that
look like XHTML, but are really XSLT;

http://www.w3.org/TR/xslt#result-element-stylesheet

Mark.

On Thu, Apr 22, 2004 at 09:50:52AM +0200, Hugo Haas wrote:
> If I define myns:getfoo to be an HTTP GET with
> application/x-www-form-urlencoded is input serialization and
> application/foo+xml, then I can make use of it with:

But it's still an HTTP GET, so I'd recommend not hiding that
fact by requiring that it be extended.

>   <http:operation method="myns:getfoo" />
> 
> My proposal was saying that, considering issue 54 and issue 147
> together, the method name, i.e. the first column of the table, merely
> becomes a shortcut to talk about a set of default values, and one
> could do the same, in a self-descriptive way, with:
> 
>   <http:operation method="GET"
>                   inputSerialization="application/x-www-form-urlencoded"
> 		  outputSerialization="application/foo+xml" />
> 
> or, if you consider that application/x-www-form-urlencoded is the
> default inputSerialization for GET:
> 
>   <http:operation method="GET"
>                   outputSerialization="application/foo+xml" />
> 
> However, the advantage of Dave's method is that myns:getfoo can
> specify that the URI style must be used in the interface operation in
> order to properly serialize the request, which wasn't the case in my
> proposal.
> 
> Sure, we can say that application/x-www-form-urlencoded requires the
> URI style, but there probably are other media types that will require
> other constrained styles and that won't be expressible with the
> solution I proposed.
> 
> With the friendly amendment of using unique identifiers everywhere, I
> think that Dave's proposal does the trick, although one is forced to
> specify what the method means before using it in the WSDL instead of
> just specifying it in the WSDL. I'd be happier with my proposal if
> there was a way to link the serialization and the interface operation
> style, but I don't see any.
> 
> Regards,
> 
> Hugo
> 
> -- 
> Hugo Haas - W3C
> mailto:hugo@w3.org - http://www.w3.org/People/Hugo/



-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Thursday, 22 April 2004 16:50:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:30 GMT