inputSerialization - was: Re: Agenda - 27 Feb @ 14:30 UTC

Lee Feigenbaum wrote on 02/25/2007 05:51:49 PM:

> 5. protocol status
> Elias is looking into the WSDL ramifications of supporting 
> application/sparql-query as an input serialization for the protocol. Not 

> sure if there's anything to discuss here this week.

I've done more looking into this. To recap where we stand, Bjoern sent 
this message in September: which he suggested adding application/sparql-query to the 
whttp:inputSerialization attribute of the "query" operation. Bjoern 
surmised that this would allow clients to post SPARQL query documents 
directly to the server.

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: Serialization rules for XML messages ( ), we 
see that there are serialization rules given explicitly for 
application/xml. These rules are at 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 ( ) 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>SELECT * WHERE { ... } </st:query>

By looking at the minutes from our 10 Jan 2006 telecon and subsequent 
mailing list messages, I do not believe that this is what Kendall (and the 
rest of the WG?) had in mind when we made this change:

(Kendall, can you comment as to whether I'm interpreting those records 

Continuing in we see that any serialization other than 
application/xml, multipart/form-data, or application/x-www-form-urlencoded 
must be serialized just as application/xml would be, but the message's 
HTTP Content-type header must be set to the appropriate type 
(application/sparql-query in this case). This does not seem to be the 
behavior Bjoern is looking for.

...all of which seems to leave us with a few options/questions:

1/ Eliminate application/xml from our list of accepted input 
serializations. To some extent, this addresses the confusion Bjoern had 
initially (why application/xml and not application/sparql-query). Does 
anyone know of any servers or clients that use application/xml 

2/ Figure out how to allow for POSTed application/sparql-query documents 
in the manner Bjoern suggests. I am not sure what this entails, or if its 
even doable in WSDL 2.0.

Elias and Kendall, do you have any thoughts on this?

Perhaps we can discuss at the telecon tomorrow, time permitting...


Received on Tuesday, 27 February 2007 01:25:36 UTC