Re: Multiple whttp:inputSerialization

Jonathan,

Thanks for your reply. I'll take your reply regarding the extension path
to support application/sparql-query to the DAWG and see if it suits our
needs. I'm ok with your resolution to not solve this at this stage in
your timeline and would support you moving to PR.

Elias Torres
DAWG (IBM)

Jonathan Marsh wrote:
> WSDL 2.0 only supports three kinds of serialization for XML data (e.g.
> described by an XML schema language and therefore with a content model of
> #any or #element): application/x-www-form-urlencoded, multipart/formdata,
> and application/xml and it's compatible media types.
> 
> Unknown media types such as application/sparql-query aren't directly
> supported - although by defaulting unknown media types that are compatible
> with application/xml are.  E.g. application/wsdl+xml would be serialized as
> application/xml.
> 
> So, how would you describe the serialization of application/sparql-query?  I
> assume you want to continue to support application/x-www-form-urlencoded, so
> you aren't likely to switch out the whole XML-based type system in favor of
> something else (even if you were there is no guarantee of interoperability -
> the spec leaves open the serialization in this case).  That just leaves
> extension as the only way to change the behavior that you seek.  For
> instance you could define an extension as follows:
> 
> <wsdl:binding ...>
>   <sparql-extension:support-sparql-query-media-type wsdl:required="true"/>
>   <wsdl:operation ...
> whttp:inputSerialization="application/x-www-form-urlencoded,
> application/sparql-query">
> 
> Processors that understood it would be able to correctly serialize the
> message using whatever rules you defined, and other processors would have
> adequate warning that they would not understand how to process the
> operation.  The spec for such an extension would indicate the precise
> details of serialization, including which parameters are serialized in the
> URL and how the body is constructed, as well as some formalisms such as how
> the component model is affected (probably just add a Boolean {supports
> sparql-query media type} property).
> 
> I had opened a bug [1] on this issue during our return to Last Call.  Since
> there isn't anything that appears to be fixable at this late date in WSDL
> 2.0 the WG voted to close the bug without any action.  If this resolution
> isn't acceptable please let us know within a week - at that time we expect
> to move to PR.
> 
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4458
> 
> 
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>  
>> -----Original Message-----
>> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
>> comments-request@w3.org] On Behalf Of Elias Torres
>> Sent: Friday, March 30, 2007 11:51 AM
>> To: public-ws-desc-comments@w3.org
>> Subject: Re: Multiple whttp:inputSerialization
>>
>>
>> Let me be a bit more specific of what we are trying to describe using
>> WSDL.
>>
>> Currently we support x-www-form-urlencoded:
>>
>> POST /sparql/ HTTP/1.1
>> Host: www.example
>> User-agent: my-sparql-client/0.1
>> Content-type: application/x-www-form-urlencoded
>>
>> query=SELECT...&default-graph-uri=A&named-graph-uri=B
>>
>> But we would also like the following:
>>
>> POST /sparql/?default-graph-uri=A&named-graph-uri=B HTTP/1.1
>> Host: www.example
>> User-agent: my-sparql-client/0.1
>> Content-type: application/sparql-query
>>
>> SELECT ?s ?p ?o
>>
>> Basically, although some folks believe it would be nice to have the
>> ability to POST application/sparql-query documents, we still need the
>> ability to specify default-graph-uri, named-graph-uri and so on. The
>> only way to do that would be to specify it in the URI, but I'm sure
>> that
>> this will be stretching WSDL a bit. Please let us know if this is
>> sensible or not, so we can proceed to notify our commenter the results
>> of our investigation.
>>
>> Sincerely,
>>
>> Elias
>>
>>
> 
> 
>

Received on Tuesday, 24 April 2007 15:06:24 UTC