From phil.hunt at oracle.com  Sat Jun 25 13:48:37 2011
From: phil.hunt at oracle.com (Phil Hunt)
Date: Sat, 25 Jun 2011 10:48:37 -0700
Subject: [Igf-dev] New Dynamic Query Element
Message-ID: <62F056CC-AE29-4DAA-BAD7-3A39014F9F6C@oracle.com>

This post is about a new extension to CARML which enables filters that are more dynamic in nature. With some exceptions, the original design for CARML was baed on the observations that very few applications, when observed, query in random or dynamic ways. Applications tend to search using very common patterns. CARML was intended to reflect this.

However, there has been continued observation that there are times when query filters are not as predictable. This situation occurs with applications that have "query builder" interfaces that allow end-users to enter search terms of their choosing to form a filter. Another example is a "directory" web page that again, presents a lot of possible attributes and allows the user to fill in fields of their choosing.

In the original CARML spec, the phone book/directory case was handled by a rather long and ugly static filter declaration that included ANDed sub filters of a long list of "optional" AttriRefFilters each with a "dynamic" operator set.  This allowed the search form to function while allowing privacy auditors to see what fields "may" be queried.

The query builder case gets a little more sophisticated and essentially means that the ands and ors of terms could also be changed during execution.

The proposal is to create a new "DynamicFilter" sub-element that extends the "Filter" element. DynamicFilter allows AttrRefFilter, PredFilter, RoleFilter sub-elements, but unlike Filter does not allow sub-filters.  What a DynamicFilter says is that any filter, simple or complex, MAY be constructed based on the list of attribute, predicates, roles specified. While this doesn't tell the infrastructure manager or the privacy auditor what exact query will be issued, it still informs the auditors about what data may be searched. Accordingly developers would be encouraged not to use broadly scoped declarations (totally dynamic) as they may be rejected from a governance perspective or from the simple perspective that in order for queries to work, correct infrastructure 'index' settings must be set based on some anticipated notion of what the app will do.

DynamicFilters must be contained within a parent Filter object and further more than one DynamicFilter is possible. This allows combinations of static and dynamic filters which allow the developer/administrator to potentially add static constraints to a filter to limit its scope.  For example:
    <Filter match="any">     
        <Filter match="all">              
             <attributeref name="accountstatus"..
             <DynamicFilter>
		<attributeref name="uid"/>
		<attributeref name="mail"/>
		<attributeref name="accountid"/>
		<attributeref name="ssn"/>
             </DynamicFilter>                               
        </Filter>
        <Filter match="all">
             <attributeref name="o"..
             <attributeref name="status"..
             <DynamicFilter>
		<attributeref name="uid"/>
		<attributeref name="mail"/>
		<attributeref name="accountid"/>
		<attributeref name="employeeid"/>
		<attributeref name="ssn"/>
             </DynamicFilter>                               
        </Filter>
    </Filter>

Note that for each dynamic filter above there is a slightly different set of attributes to search against. There is also no stated filter relationship between the search terms. From the example shown, there could be an implied "ANY" relationship between terms, but there could also be multiple levels also defined at run time -- as long as each filter term was included in the parent dynamicfilter.

This new schema should be backwards compatible with any existing declarations. I will post code shortly that implements this proposal.

Comments and concerns?

Phil

@independentid
www.independentid.com
phil.hunt at oracle.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/igf-dev/attachments/20110625/f07cf310/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: arisid-igf-carml-v1.1.zip
Type: application/zip
Size: 2826 bytes
Desc: not available
Url : http://lists.openliberty.org/pipermail/igf-dev/attachments/20110625/f07cf310/attachment.zip 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/igf-dev/attachments/20110625/f07cf310/attachment-0001.html