W3C home > Mailing lists > Public > public-sparql-12@w3.org > April 2019

Re: Thoughts about backwards compatibility (and DESCRIBE)

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Wed, 24 Apr 2019 18:46:05 -0400
To: Bob DuCharme <bob@snee.com>, public-sparql-12@w3.org
Message-ID: <27a987b0-2ee5-1ac0-74f0-217c967a401f@gmail.com>
How strict?  And to what?

The strictest I can think of is only allowing extensions to the query language
(syntax and semantics) where extensibility is explicitly allowed in SPARQL 1.1
Query Language http://www.w3.org/TR/2013/REC-sparql11-query-20130321/ and
similarly for the other parts of SPARQL 1.1.

peter


On 4/24/19 6:36 PM, Bob DuCharme wrote:
> I agree that people should be able to assume strict backward compatibility
> until we're talking about SPARQL 2.0.
> 
> Boris's comment did remind me of something that would be nice to add to the
> 1.2 wishlist: a clear specification about what the DESCRIBE keyword should
> return instead of just leaving it up to the "information publisher"
> (https://www.w3.org/TR/sparql11-query/#descriptionsOfResources) to decide.
> This is vague enough that as far as I know no one even uses this keyword,
> because if using one query processor is going to give you different triples
> from another processor when you make the same request, you may as well just
> use a CONSTRUCT query so that you know what you're getting. (As a former
> employee of a company that marketed an RDF platform, though, I know that
> employees of such companies don't worry so much about how other query
> processors would handle their queries.)
> 
> Thanks,
> 
> Bob
> 
> 
> On 4/24/19 10:58 AM, Boris Pelakh wrote:
>> Given that this is SPARQL 1.2, semantic versioning would require strict
>> backward compatibility, since the major version is not changing. Nor have I
>> seen any proposals that would require a compatibility-breaking change.
>>
>> In the cases where the previous standard behavior is undefined, or vendor
>> dependent, or non-existent, the new standard can mandate anything without
>> breaking compatibility.
>>
>> Boris Pelakh
>> Ontologist, Developer, Software Architect
>> boris.pelakh@semanticarts.com
>> +1-321-243-3804
>>
>>
>> -----Original Message-----
>> From: Jerven Tjalling Bolleman <Jerven.Bolleman@sib.swiss>
>> Sent: Wednesday, April 24, 2019 6:15 AM
>> To: SPARQL 1.2 Community Group <public-sparql-12@w3.org>
>> Subject: Thoughts about backwards compatibility
>>
>> Hi All,
>>
>> I thought to quickly write about my thoughts regarding backwards compatibility.
>> These are just my thoughts and I am just providing them for discussion.
>>
>> My feelings on the matter are that there are two kinds of backwards
>> compatibility.
>> The first is "formally" not backwards compatible, i.e spec A says a certain
>> kind of query should return a specific result and spec A+ defines a second
>> different result, then it is not formally backwards compatible.
>>
>> Second is the "marketplace" backwards compatible.
>> Same situation as above, but no one ever implemented A as specified or
>> no-one ever send that kind of query.
>> Then while there is a formal change in behaviour no one is impacted because
>> no one used the behaviour.
>>
>> I am OK with breaking "formal" backwards compatibility but I am not at all
>> keen on breaking "marketplace" backwards compatibility.
>> In that regards I see as an example to follow the Java language stewards
>> whom have the same kind of problem.
>> There is a lot of code in the wild, doing even wilder stuff, making money
>> and solving problems.
>> Breaking such code should only be done in extremis and after careful
>> evaluation.
>>
>> Being a very small community I think we can't afford splits like python2 to
>> 3 or even worse Perl5 to 6.
>>
>> Regards,
>> Jerven
>>
>> -- 
>> Jerven Tjalling Bolleman
>> SIB | Swiss Institute of Bioinformatics
>> CMU - 1, rue Michel Servet - 1211 Geneva 4
>> t: +41 22 379 58 85 - f: +41 22 379 58 58 Jerven.Bolleman@sib.swiss -
>> http://www.sib.swiss
>>
> 
Received on Wednesday, 24 April 2019 22:46:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 April 2019 22:46:31 UTC