W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: SPARQL 1.1 Protocol: Format of fault messages

From: Richard Newman <rnewman@twinql.com>
Date: Sun, 3 Oct 2010 14:06:56 -0700
Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
Message-Id: <5C402EEE-90C7-4470-8439-CF5FCDD320DE@twinql.com>
To: Richard Cyganiak <richard@cyganiak.de>
> * XML?
>
> The SPARQL Result Format already is XML, so clients already have a  
> parser and are using it.

I said "modern" and "simple" ;)

(I also said "structured", which is an argument against XHTML -- the  
precise structure isn't known in advance. When "just use SAX" is part  
of the answer, something is awry.)

I slightly disagree with you: not all "clients" are singular.

I've seen plenty of tools which catch errors, but pass success through  
to something else. (Think of an editor which invokes a compiler: it  
presents the error messages to the user, but passes the 'success'  
output -- object files -- to the linker. Your editor does not  
understand object code.)

These tools will not necessarily themselves be XML-aware, but must be  
able to catch and display errors.

I also favor content negotiation for SPARQL Protocol clients and  
servers, too, so even then I don't necessarily expect XML capability.  
I view XML as something of a legacy technology, supported for backward  
compatibility with those heavyweight Javaesque tools that don't  
support anything better...


> Clients don't necessarily have a JSON or Turtle parser on board, and  
> while especially JSON parsers are easy to get by these days, and are  
> just a few K of code, demanding one just for error messages would be  
> a bit strange IMO.

Indeed... but I'd say a JSON parser is less of a burden on a client  
than an XML parser, which is less of one than an RDFa parser.

(Form-encoded is even less of one, of course.)


>> We have this magic technology called "content negotiation", so how  
>> about we use it?
>
> +1. The spec could recommend one of the simple machine-readable  
> options as the normal format, and mention that implementors MAY  
> offer other options via content negotiation.

Sounds good to me. I also like the header approach, though I'm sure  
someone will complain that common HTTP libraries don't always give  
access to response headers.

The main reason I spoke up is that I didn't want to see the spec  
gradually drift towards "nobody uses anything but X(H)TML in Java to  
process responses, so let's use that for everything".
Received on Sunday, 3 October 2010 21:07:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 3 October 2010 21:07:54 GMT