- From: Kendall Clark <kendall@monkeyfist.com>
- Date: Tue, 16 Aug 2005 09:33:12 -0400
- To: Hugo Haas <hugo@w3.org>
- Cc: www-ws-desc@w3.org
On Tue, Aug 16, 2005 at 03:01:45PM +0200, Hugo Haas wrote: > > I don't see why it would not work. However, what you are going to end > up with is a POST of an empty message to a IRI built based on the > instance data, and I don't think that it's the solution you were > after. Ah, yes, you'd think after all these years, I'd grok how POST works. :> > Didn't you want to use multipart/form-data is an input serialization > instead? And in which case, yes, you can do it. Yep, I somehow convinced myself that multipart/form-data wouldn't work. Oh, well, thanks. > The value of whttp:outputSerialization is "a IANA media type > token"[1], which interestingly doesn't have a reference to define it > clearly, but I don't think that it allows something like > "application/*", or "application/sparql-results+xml > application/rdf+xml", or even "application/sparql-results+xml, > application/rdf+xml". Yes, that's my reading of the specs, too. Precisely what we want is to be able to list multiple IMTs as possible output serialization types. What I really want from WSDL 2 is to be able to describe *my* service, not to have to change my service to fit WSDL 2 (especially in cases like this, where there doesn't seem to be anything *wrong* with multiple serialization types from a single operation). > So WSDL doesn't allow you to do what you want to. Right. Bad WSDL! :> > Talking to Eric Prud'hommeaux about this, we actually wondered what > would happen if one was declaring two binding operations with > identical input parameters but different output ones: Eek. That's ugly. I'll pass on that. :> > But it's ugly in this case. Agreed. Hugely complicating and complex. And implicit. > It actually may be possible to change the definition of the > serialization properties to allow for a list of media types instead of > one particular media type. Yes, I suspect I will send LC comments to this effect. > Maybe the fault serialization should be a property of the Binding > Fault and Binding Fault Reference components, rather than of the > Binding Operation, which would solve your problem. That makes sense; does it solve my problem because, as a property of Binding Fault, it would be optional? The other way to solve it is as per outputSerialization above, namely, to allow a list of multiple IMT values. But we'd prefer it to be optional, in which case we just wouldn't specify it. A partial, more accurate description is better than a more complete, but less accurate one. IMO, of course. :> > As WSDL 2.0 is in LC until 19 September, I encourage you to send all > the feedback you may have as a result of this discussion to > public-ws-desc-comments@w3.org. Thanks, Hugo. And, yes, stay tuned, as I suspect some LC comments will be forthcoming. Best, Kendall Clark
Received on Tuesday, 16 August 2005 13:33:24 UTC