Re: [higgins-dev] Filters, Comparators, and Model (Schema)

["Tom Doman" <TDoman@xxxxxxxxxx>]

Ok, here are some examples:

Example 1:
Find all Digital Subjects whose "firstname" has "equality" with "bob".

This is one where standard assumptions typically work out fine.  "firstname" is defined in the model to ultimately be a string which can be compared for equality with another string via a standard string exact match or case-insensitive comparison.  An assumption that the assertion value format is also a string (ie. "bob") also typically works out fine.  In IdAS, we currently have the ability to specify a different comparator and pass that to the CP, so that's good.  However, the IdAS user does not know, even for the standard assumption in this example:

1. whether the CP supports the comparator the IdAS user has chosen.
2. in what format the assertion value can be handled.

The IdAS user simply hopes the standard assumptions are supported.  We've defined a suggested minimum set of "standards" but the IdAS user still is beholden to the CP in the dark.

Example 2:
Find all Digital Subjects whose "firstname" has "substring match" starting with "th" and ending with "as".

This is one where the comparator requires more than a single assertion value as well as, in this case, an indication of what each assertion value is to be used for.  We're currently unequipped to do so in IdAS.

Next, I'll be trying to put out a proposed solution to these issues in terms of IdAS interfaces.  Anyway, I guess I hinted at some of our approach below.  In the mean time, does anyone have any thoughts, comments, or suggestions on this so far?

Tom

>>> "Tom Doman" <TDoman@xxxxxxxxxx> 11/07/06 4:57 PM >>>
Lately, I've been looking at implementing a string format for filters for use by one of our bandit components.  As I started into that, I've discussed with Jim some of the unresolved issues surrounding Filters in IdAS.  The main issue surrounds what we've called comparators in IdAS.  The interface we have right now has several issues:

1. It requires compile time knowledge of what kinds of comparators and comparators themselves are allowed and used for a given attribute type.
2. There is no way to accommodate complex comparators which require more than just a single assertion value.
3. There is no way to determine the format required for an assertion value that goes with a given comparator.

Many times, we make assumptions on all of these that work out fine.  Anyway, after discussing this with Jim, we are starting to believe that the best way to rectify this is require attribute model definitions to specify what the kinds of comparators they support (ie. Equality, Ordering, Substring, etc.), the actual comparator used, and the assertion value format.  Then, at run time, the IdAS consumer may query this information to properly build filters.  This could possibly just be an extension of Valery's model work, though neither Jim nor I are sure what all the interfaces represent there.

I want to try to put out some examples but I wanted to see if anyone else has given this area some thought and has any comments or suggestions.

-Tom

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/higgins-dev