Page History

Having a fluent interface in my opinion would be way more intuitive and practical. E.g.

//AND of two restrictions

Restriction and(Restriction firstRestriction,  Restriction secondRestriction)

//OR of two restrictions

Restriction or(Restriction firstRestriction,  Restriction secondRestriction)

//NOT of a restriction

Restriction not(Restriction restriction)

This will give any user of the API an intuitive way to build a complex query and the developer a tree to navigate and translate to SQL (or any other query language). A developer could do something the likes of myQuery.setRestriction(restriction1.and(restrcition2).and(restriction3))

How do control how many attributes we get back?

Maybe we dont need this because we dont have complex data attributes

We have the following options

1. Default is no attributes 
2. All Attributes
3. Specify attributes - output specification (filter)

Maybe we could just have a 

3 Alternatives 

1. all in one interface
2. Limited number of interfaces e.g Data Objects/ Data Persistence/Query
3. Very fine grained (see below)

peristenceStore.addChild(parentDataObject, childDataObject)

Change Data SPI to DataStore - methods to add data. 

We will not have a querybuilder in SPI but the SPI will have to understand the query.

API - construct the CPS path 

SPI - deconstruct it and convert it into a query  

From an end user perspective anchor and fragment are different - we should separate them 

CpsAdmin Interface will handle the datastore and anchor

access control? extend the CpsAdmin

Module SPI - responsible for handling modules and module sets

QueryBuilder - responsibility of API