Re: draft response to Nicholas J Humfrey

On Mar 4, 2010, at 2:39 PM, Andy Seaborne wrote:

>> Draft response:
>> http://www.w3.org/2009/sparql/wiki/CommentResponse:NH-1
> 
> Looks OK to me - I don't see that adding the information is that helpful band when HTTP content negotiation is the usual pattern here.

I assume the argument would be that it would allow an application/user to plan ahead when requesting a format that might not be supported. If JSON is desired, for example, this would allow you to know that you'll get back JSON, or be able to plan ahead for using XSLT (or something similar) without having to submit a query and get back an error (HTTP 406?) or (worse) an unexpected media type. As noted earlier, I'm not totally familiar with all the WSDL stuff surrounding the protocol, but I'm not sure the protocol document spells out exactly what happens in a case like this. Having this information available in the service description would bring some level of predictability to the situation.

>> I'm not sure something like the discussed saddle:resultFormat property is appropriate in the SD doc for the same reasons that I've pushed back on other features that reach outside of the SPARQL specs. My previous email regarding the 1.1 Protocol draft touches on this, but can anyone tell me if a conformant protocol implementation has to support the SPARQL XML Results format and RDF/XML?
> 
> They do, indirectly as the only standard serializations of a result set and a graph (RDFa noted).

Agreed w.r.t. the SPARQL XML Results format, but that's not how I read the protocol document regarding RDF graphs. I don't see anywhere where it's said that responses must use standard serializations (only that the response must be an RDF graph, "for example, in the RDF/XML syntax, or an equivalent RDF graph serialization").

>> If there is a range of formats that a conformant protocol implementation can support, should the service description enumerate the supported formats? Also, does RDFa change anything here as the (only?) other standard serialization format (you could imagine an implementation emitting CONSTRUCT results as RDFa)?
> 
> The MIME type for RDFa is XHTML (and soon HTML).  So it's not quite on the same footing; it can encode a graph but it's designed add information inside XHTML.

I agree that it doesn't seem like the same footing, but given the loose wording in the protocol document, it seems legitimate (if a bit perverse) to return RDF data as RDFa.

.greg

Received on Thursday, 4 March 2010 20:19:27 UTC