Re: SPARQL 1.1 Protocol: Format of fault messages

* Richard Newman <rnewman@twinql.com> [2010-10-03 14:06-0700]
> >* XML?
> >
> >The SPARQL Result Format already is XML, so clients already have a
> >parser and are using it.
> 
> I said "modern" and "simple" ;)

hmm, no corba, then?


> (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.

So we have to decide whether there are or will be sufficiently more
intermediaries with JSON and without an XML parser than end clients
with XML parsers to warrant involving an extra language.


> (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".

I'm motivated by two factors: somewhere in the pipeline is a tool
which already parses XML, and the far majority of SPARQL endpoints
cater to browser use. The latter seems very healthy.

In exchanges where the client has indicated that it parses e.g. JSON
(Accept: application/sparql-results+json per
<http://www.w3.org/TR/rdf-sparql-json-res/#mediaType>), then using
JSON seems only polite. I'd put that into doc which specifies that
format. Yes, this makes life harder for the intermediaries which 
have JSON and no XML, but that seems like a smaller community than
the XML-only clients.
-- 
-ericP

Received on Monday, 4 October 2010 01:28:26 UTC