Re: comments JP-4 how to proceed?

On 21/02/12 08:54, Axel Polleres wrote:
> Rethinking of the past Telco, and not having read any further discussion on the mailinglist,
> I think that some things became clear in the context of comment JP-4:
>
> Option 1 is not viable, and Option 2 seems to turn out just too late in the game,
> particularly since there is little/no resources to spec it out, even if there was two
> possible implementors (Andy+Matt).

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.

> So, unless someone jumps up to spec out the feature by the end of the month, the obvious
> way to proceed seems Option3, i.e. leave things as they are, and put something like ALLPATHS
> or DISTINCT() around paths as a proposal which could be considered on the future_items
> list and send a reply along these lines to JP-4.

Default to unique solutions is a bad design as a holding pattern - it 
breaks the transformations; it does not do what you might expect because 
the rest of the graph pattern does not produce distinct subsets of 
bindings.  It breaks aggregations.  It does not leave open the way to 
path length handling.

> 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

> best,
> Axel

	Andy

I have implemented DISTINCT() on paths or path components, now with an 
implementation specific to DISTINCTness.  Available in ARQ development 
build in the extended language.

http://s.apache.org/UgJ

Received on Tuesday, 21 February 2012 10:17:46 UTC