...
Description | Details | Decisions | |
---|---|---|---|
1 | Assume flat attributes (no complex data types) but data could be stored as json object in SPI impl. for convenience/PoC | ||
2 | SPI Implementation NOT using Model (service) current ENM SPI does! | ||
3 | Are we going to have XPath/query builder? |
| |
4 | 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 of the API 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)) | ||
5 | When do we get attributes? | Maybe we dont need this because we dont have complex data attributes | |
6 | Should we use the name node or fragment? | ||
7 | Do we want to split the interface? | Maybe we could just have a 3 Alternatives
|
...