- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Tue, 10 Jul 2018 11:32:32 +0200
- To: Jörn Hees <j_hees@cs.uni-kl.de>
- Cc: public-sparql-dev@w3.org, Thomas Francart <thomas.francart@sparna.fr>
SPARQL result format is XML and has namespaces, so I would expect XML-aware parsers to simply ignore the XML elements outside of the http://www.w3.org/2005/sparql-results# namespace. Isn't that so? XML namespaces get a lot of hate, but such extensibility is exactly the use case for them. It's the JSON format that would have a bigger problem accommodating custom elements.= IMO. On Mon, Jul 9, 2018 at 8:08 PM, Jörn Hees <j_hees@cs.uni-kl.de> wrote: > Hi, > >> On 9 Jul 2018, at 13:56, Olivier Rossel <olivier.rossel@gmail.com> wrote: >> >> Can't the HTTP headers contain such informations, instead of the XML resultSet ? > > I'd actually argue that some important meta information should always be part of the result document so that it's very visible and explicit. > I remember getting into a lengthy discussion with Kingsley once (https://github.com/openlink/virtuoso-opensource/issues/112) because of Virtuoso's partial answers that are served as a 200 with an additional header. > The problem is that end-users (and developers) are very likely to miss such crucial meta info. > > That said, I definitely agree that I had use-cases before in which i would've loved standardized meta info such as: > - is the result complete (maybe "exhaustive" is a better term) or should it be treated as partial? (also think of open / closed world in federation / sponging...) > - did the server reach any boundaries during processing? (limits/timeouts explicit or implicit) > - timing info: how long did the server need to generate the results? (independent of http transmission speed, maybe even in wall / cpu time to get a better measure of computational cost) > - how busy was the server at the time of answering the query? (e.g., number of concurrent queries, cpu load) > - query planner information (e.g., which execution order was chosen because of how many candidates) > > So maybe Thomas isn't really alone in his desire to add some meta info and the next result spec could be extended with some common meta info fields? > > Best, > Jörn > >
Received on Tuesday, 10 July 2018 09:32:56 UTC