Re: Revised proposed Issue 54 resolution

* David Orchard <dorchard@bea.com> [2004-04-21 14:25-0700]
> Hugo, why can't we do as you suggest and add put and delete, and then
> define default behaviour for extensibility, as I proposed?

Looking at your proposal below:

* David Orchard <dorchard@bea.com> [2004-04-21 14:10-0700]
> 
> A revised issue 54 resolution text, after Jonathan pointed out that the current solution isn't extensible.
> 
> I have added PUT, DELETE, and name extensbility.  It proposes that a bare name name must have xml inputs and outputs, and qname name is undefined but allowed. 
> 
> Text for 3.1.1 table.
> 
> Table 3-1. Methods, serialization format, and HTTP methods Method Input serialization Output serialization HTTP Method Message Patterns Operation Style 
> "post" application/xml application/xml HTTP POST In-Only, Robust In-Only, In-Out any 
> "get" application/x-www-form-urlencoded application/xml HTTP GET In-Only, Robust In-Only, In-Out URI style 
> "form-data-post" multipart/form-data application/xml HTTP POST In-Only, Robust In-Only, In-Out Multipart style
> "put" application/xml application/xml HTTP PUT In-Only, Robust In-Only, In-Out any 
> "delete" application/x-www-form-urlencoded application/xml HTTP DELETE In-Only, Robust In-Only, In-Out URI style 
> (any) application/xml application/xml HTTP (any) In-Only, Robust In-Only, In-Out any 
> (any) any QNAME with a prefix implementation-defined implementation-defined

Considering the line which is last to one, that would mean that "put"
and "PUT" as well as "post" and "POST" would basically be equivalent,
but "get" and "GET" wouldn't, right?

Since the last line can do what the bare name does, I think using
QNames or URIs everywhere is clearer and less confusing.

* Mark Baker <distobj@acm.org> [2004-04-21 20:22-0400]
> Looks good for the most part, but shouldn't more specific XML media
> types (*/*+xml) be supported, even if you're only describing XML
> in/out?
> 
> I know this was part of Hugo's proposal, I just wasn't able to respond
> at the time he made it.

Actually, I think that the last line proposed by Dave also solves
issue 147, from an indirect prespective.

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:

  <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/