Re: [higgins-dev] Producer of user-supplied IdAS objects

["Jim Sermersheim" <jimse@xxxxxxxxxx>]

>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 3/12/07 9:07 AM >>>
>Jim,
>
>I propose to add some changes to IFilter interfaces:
>
>1. Now filter can contain only one assertion because there is "IFilter.OP_NOT" operator which does not allow to have more than one assertion per a filter.  As a result we need to encapsulate each assertion into its own Filter. I propose to remove IFilter.OP_NOT (user can inverse an assertion condition instead of using this operator).  As a result we will able to add any number of assertions to the same filter.
 
Can you talk more about the need to remove this?  If it's only for the inconvenience of having a single assertion inside an IFilter, I'd rather address it from a "making things simple" point of view, because I think "inversing an assertion condition" gets rather complicated for the user, and will produce different semantics than I think people will expect.  For example (let's use Java expressions for readability):

!(a=1) becomes (a!=1).  We need to address semantics of multi-valued attributes.  If a contains 1 and 2, then !(a=1) is false and (a!=1) is true.  Ignoring semantics...
!((a=1) || (b=2)) becomes ((a!=1) && (b!=2)).  Not too hard to figure out, but a little klunky.
!((a=1) && (b=2)) becomes ((a!=1) || (b!=2)). Same as above, but less intuitive for people to think about.
!(!((a=1) || (b=2)) && (c=3)) becomes ((a=1) || (b=2) || (c!=3)).  At least I think that's right.  I might need Mister DeMorgan to check my math.

What if we came up with a string-representation of a filter, so people could use that when they're dealing with simple values?  Something like what we started in http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg00878.html. That would make building filters much easier for IdAS consumers.

>2. Add to IFilter interface some methods like addAttributeAssertion(URI type, String comparator, IPropertyValue, boolean bIncludeSubtypes) that will create and add an assertion to the filter.
 
Yes, we need these. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177060)

> 3. Remove IFilter.createCUIDAssertion() method (and IFilterCUIDAssertion interface) because subjectID now is an attribute.

I left this here only as a shortcut.  In reality, it's probably unlikely that people will filter on cuid much anyway, since once can directly read a subject by supplying the cuid.  Where it would be useful is in testing a set of attributes on a subject (i.e. asking if "bob" has a ssn=123-454-6789 and a phoneNumber=221-555-9989).  If people don't think the convenience is worth it, let's remove.  Any other opinions?
 
> 4. Remove  IFilterPropertyAssertion.COMP_PROP_INFERRED_REL_EQ comparator because DigitalSubject does not implement IHasRelationships interface now.

Good catch. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177061)
 
> 5. Add to IFilterPropertyAssertion interface some new comparators like  GT, LT (now only GE and LE are present), notEqual, equalIgnoreCase, substringIgnoreCase, e.t.c.

OK (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177062).  Also remember that anyone can also use any known comparator string (it would be nice if we had a registry of these things).  On the need for notEqual... do we need this if we retain the IFilter.OP_NOT operator?
 
> 6. Define default value of "includeSubtypes" parameter for IFilterAssertion.

Agreed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=177063).  Anyone have a preference?  I could go either way.
 
> 7. Remove setAssertionValue(URI assertion) method from IFilterTypeAssertion interface because there already is setType(URI id) method.

The setType() method is used to set the type of the assertion value.  The type of an IFilterTypeAssertion is implicit, and the value is the subject's type (not the assertion's type).  Think of it this way:  Pretend we didn't have IDigitalSubject.getType().  Pretend instead like there was an attribute called "higgins#subjectType".  Then we would use an IFilterAttributeAssertion with the type set to "higgins#subjectType", and the value set to something like "higgins#person".  Since we decided to make a subject's "Type" not an attribute, I added this assertion, but the semantics are as if it were an attribute. It's just that it's type is implicit (setType should not be called).  This assertion value is made up only of comparator and assertion value
 
>Thanks,
>Sergey Lyakhov

Jim