- From: Gregory Williams <greg@evilfunhouse.com>
- Date: Mon, 27 Feb 2012 15:49:39 -0500
- To: Axel Polleres <axel.polleres@deri.org>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>, Andy Seaborne <andy.seaborne@epimorphics.com>
On Feb 27, 2012, at 7:35 AM, Axel Polleres wrote: >> I willing to spec for 2.1 (DISTINCT modifier on path components) but not >> in the framework you outlined in the telecon which was to produce all >> the spec material, then decide which option the WG will pursue. I don't >> think people will engage in a process to come up with the necessary >> design on the basis it might all be thrown out based on reasons we have >> before the spec work starts. > > Ok, so how do the other s think here? Andy's is the only answer I got. > Given that he volunteers to spec it out, can we have a vote on whether we are > willing to bring this into the spec (particularly, also as there was a slight majority > on the call two weeks ago for the DISTINCT() option): > http://www.w3.org/2009/sparql/meeting/2012-02-14#line0064 I'm not sure when I'd have time to actually implement the new semantics, but I'm willing to support this plan so long as we believe it will satisfy those commenters who have indicated resistance to the current state of property paths. If we're going to be making a big change like this, though, does this open the door to considering other outstanding issues that would have caused another LC round (e.g. Dave Robillard's concerns about property path syntax restricting future updates to prefixnames)? >>> Let me know if anyone thinks different. >>> >>> BTW: As for the related comment JP-5, it seems obvious that not all implementations >>> cover the current property-pths semantics uniformly, and that we need to fix this before going to PR. >> >> ?? That's what the implementation report is about > > As I read the process doc, in the entrance criteria for PR we should have two interoperable > implementations: If what comment JP-5 says, then this is not given at the moment, right? Team? I think the issue here is that it sounds like the test suite isn't currently covering enough cases to reveal the differences in the implementations that JP-5 mentions. We should make sure we agree with the semantics in the test case JP-5 proposes, and then add it to the test suite (along with any other tests we can think of that might cover un-tested parts of the path semantics). .greg
Received on Monday, 27 February 2012 20:50:05 UTC