[Mulgara-dev] New "commit" developer

[Andrae Muys]

On 02/03/2007, at 8:40 PM, Life is hard, and then you die wrote:
> Finally, on a more productive note (;-)) we've developed a simple
> string-comparison resolver which currently implements string-based
> case-insensitive equals, <, <=, >, and >= (this is mostly for
> literals, but will work on URI's too). It's modeled on the
> prefix-resolver. Currently the object may not be varialbe (i.e. only
> comparisons against constants are supported), but with Andrae's info
> from a few weeks back it should be possible to allow variables for
> both subject and predicate.
>
> Anyway, the point is that we're willing to donate this to the Mulgara
> codebase - are you interested? If so, does anybody feel like it
> would be a good/bad idea to merge this with the prefix-resolver so
> that all extended string-comparisons are in one resolver and model?

Sounds good, and yes it probably does make sense to combine the  
various string manipulation predicates in a single resolver, even if  
they are ultimately separated into different Resolutions.  So I agree  
you should merge into PrefixResolver, and if you could fix  
PrefixResolver to properly defer rejection of the constraint until it  
has sufficient information to actually do so that would be great.

This does remind me though that when I looked at the PrefixResolver,  
and given your questions earlier, I am convinced that the ResolverSPI  
doesn't provide sufficient guidance to resolver developers.  I have a  
few ideas, but basically I think that it was a mistake to allow  
resolver-writers to try implementing their own resolve() method - or  
at least to require them to.  A _correct_ resolve() method is really  
very minimal - it checks to see if it might become possible to  
resolve the constraint, if not it returns 'Empty', if there exists an  
interpretation of the constraint that is resolvable then it returns  
an appropriate 'Resolution'.

The reason I am thinking that the resolver SPI itself is to blame is  
that people (including myself), keep wanting to do too much in the  
resolve() method - PrefixResolver.resolve() is a classic example of  
this - rather than deferring to *Resolution::<init>() or  
*Resolution::beforeFirst().

I'm going to have to sketch a little and think about what might work  
better, but it is clear to me that what we have isn't providing the  
support resolver authors need.

Andrae

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd