- From: Richard Newman <rnewman@twinql.com>
- Date: Sun, 3 Oct 2010 14:06:56 -0700
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Eric Prud'hommeaux <eric@w3.org>, "public-rdf-dawg-comments@w3.org" <public-rdf-dawg-comments@w3.org>
> * 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 UTC