Re: Extending SPARQL XML result format

It depends on the schema. It’s straightforward to write a schema that forbids extension with or without a namespace. That doesn’t stop you from processing it but it means validating with that schema will fail. 

Namespaces do not make processing easier or harder for the most part. You can’t know whether elements from a given namespace are safe to ignore without specific knowledge and you could just have that for extra elements in a single namespace. 

> On Jul 10, 2018, at 10:33, Martynas Jusevièius <martynas@atomgraph.com> wrote:
> 
> 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:51:44 UTC