...
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
|
...