RE: Revised proposed Issue 54 resolution

Hugo,

This is very much like the XML Schema wildcard "determinism" problem.  I
suggest that we adopt what Schema has been looking at, that wildcards
are "2nd class" and are matched only when a discrete particle can't be
matched.

Cheers,
Dave

> -----Original Message-----
> From: Hugo Haas [mailto:hugo@w3.org]
> Sent: Thursday, April 22, 2004 12:51 AM
> To: David Orchard; Mark Baker
> Cc: www-ws-desc@w3.org
> Subject: 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/
>

Received on Thursday, 22 April 2004 16:05:59 UTC