in an early version of the api, what is now AttributeLookupService.search took a single IdentityPredicate as argument. The intent being that the attributes of each entity would be tested to determine if they satisfy the predicate. Given that model, we concluded that a developer would not be able to write queries to select entities based on the entity being required to contain 2 or more different attributes each needing to match an attribute specific criteria.
for example: give me all those entities that have an attribute named emailAdress and an attribute named mobilephone.
In the current version of the api, AttributeLookupService.search has been modified to take a varargs array of 0 or more IdentityPredicate arguments, where all of the argument predicates must be satisfied by each selected entity collection. This
makes it possible to compose entity queries like the example above.
when it comes to projecting attributes from entity collections, we saw a similar problem wrt to attribute properties. For example in an early version of the api, AttributeLookupServoice.getAttributes took as arguments, an entity reference, and an IdentityPredicate, and the job of the lookup service was to iterate over each of the attributes of the referenced entity, returning those that match the predicate. This mostly works when the selection is based on unitary characteristics of the attribute (i.e., name and attribute value). However an analogous problem to that seen in entity selection occurs when the attribute selection is to be predicated on the attribute containing more than one property.
for example: give me all those attributes that contain a property named issuer and a property named valid-unitl
Analogous to what was done for entity selection, in the current version of the api, AttributeLookupService.getAttributes has been modified to take one IDPredicate to be used to select attributes by name and value, and a varargs array of 0 or more IdentityPredicate arguments to further select attributed by their meta-data or properties. The job of the lookup service is to select those attributes that satisfy the attribute name value selector, and that contain a property to satisfy each of the property predicates.
This design is workable, but is limited in that it is not possible to associate different property predicate lists with different attribute name value criteria, other than by performing multiple queries. so for example it is not possible to
form a single query like the following:
give me the attribute named emailAddress if its issuer is acme.com or give me the attribute named mobilephone if its issuer is mabell.
one thought is that the initial issue and the remaining difficult might be better solved, by not specializing expressions into attribute and property categories as was done, but instead, to add s scope designator, e.g. to the conjunction predicate builder, so that we can establish whether the and is to apply to a single attribute or property, or to the set of attributes and properties.