Multiple whttp:inputSerialization

[Elias Torres-3]

Dear WG,

I'm currently one of the SPARQL protocol editors and we have received a
request [1] to add support for an additional input serialization and am
seeking your advice. We have done a review of the current documents [2] to
see if this is possible but we were unable to come up with a solution and
are hoping you can help us.  Ideally, we would like to know how to add
support for both application/x-www-form-urlencoded and
application/sparql-query in our query operation [3].

Additionally, my colleague Lee Feigenbaum believes we also support an XML
version of our x-www-form-urlencoded data by virtue of our WSDL defining
the input message parts via a reference to an XML schema element (<input
... element="st:query-request"/>), the query message has a message content
model of "element". Turning to:

6.3.2.1 Serialization rules for XML messages (
http://www.w3.org/TR/wsdl20-adjuncts/#_http_binding_default_rule_psf ), we
see that there are serialization rules given explicitly for
application/xml. These rules are at
http://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encoding and say
that serializing a message as application/xml means that the message's
instance data is serialized as Canonical XML. Further, the instance data is
explicitly defined (
http://www.w3.org/TR/wsdl20-adjuncts/#instance_data ) to be "The internal
tree representation of an input...constrained by...the XML element
referenced in the {element declaration} property of the Interface Message
Reference component".

As I read it, this means that the inclusion of application/xml amongst our
inputSerialization allows for POSTed content that looks like:

<st:query-request>
  <st:query>SELECT * WHERE { ... } </st:query>
  <st:default-graph-uri>http://example.org/graph1</st:default-graph-uri>
  <st:default-graph-uri>http://example.org/graph2</st:default-graph-uri>
  <st:named-graph-uri>http://example.org/graph3</st:named-graph-uri>
</st:query-request>

However, we don't believe that this was our intention, furthermore, our
real interest is whether we can use multiple whttp:inputSerialization
values to add support for POSTing application/sparql-query documents.

Thanks,

Elias Torres on behalf of the DAWG.

[1]
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0007
[2] http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0112
[3] http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-query.wsdl
[4] http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-types.xsd

[Elias Torres-4]

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

[Jonathan Marsh-2]

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@... [mailto:public-ws-desc-
> comments-request@...] On Behalf Of Elias Torres
> Sent: Friday, March 30, 2007 11:51 AM
> To: public-ws-desc-comments@...
> 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
>
>

[Elias Torres-4]

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@... [mailto:public-ws-desc-
>> comments-request@...] On Behalf Of Elias Torres
>> Sent: Friday, March 30, 2007 11:51 AM
>> To: public-ws-desc-comments@...
>> 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
>>
>>
>
>
>