Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Assumptions

...

#DescriptionDetailsDecisions
1How to differentiatie GET queries with different parameters. If we dont have named parameters how best to know what is meant

Alternatives

  1. GET /anchorpoint/dataspace/{dataspace} versus /anchor-point/name/{dataspace}
  2. GET /anchorpoint?dataspace={dataspace} versus /anchor-point?name={dataspace}
  3. GET /dataspace/{dataspace-id}/anchorpoint versus /anchor-point/{name}
  4. GET /dataspace/{dataspace-id}/anchorpoint versus /anchor-point/name/{name}
  5. GET /dataspace/{dataspace-id}/anchorpoint versus /name/{name}/anchor-point

GET cps/ragment/xnfProxy-left|AthloneNode?xpath="..."

GET cps/fragment/namedId=xnfProxy-left|*?xpath=a/b/c (DB has als uuid)

GET cps/uuid=123456789  (remove 'fragment') !

GET cps/nameId?dataspace="..."

xnfProxy-left|*?xpath=*/b/*/d

xnfProxy-right|AthloneNode?xpath=....

 [xnfProxy-left,xnfProxy-Right]/AthloneNode


2Advance queries v Simple Queries (gets) for data fragments. Do we want/need differentiatie on UTL?
  1. GET /fragment/query/{xpath}
  2. GET/fragment/{xpath}  
  3. GET /query/{xpath}

Note . The xpath could be a full unambiguous xpath returning one object or it could be partial path using wildcards etc allowing for more advanced queries return 0 or more fragments (developed over many iterations)


3We have no modules sets!model files just arbitrarily group a few modules, is there a need to persist this grouping (We do have the concept of a dataspace as well)

API definitions

Group#OperationPayloadDescription

Modelling storage

1PUT /module/{dataspace}FileCreate/Update (and validate) a module set. (upload a model file)
2GET /module/
Read all modules in the store.
3GET /module/{namespace} (see assumption #1 and issue #1)
Read all modules in the store for the given namespace
4GET /module/{namespace}/{revision}
Read all modules in the store for the given namespace and revision
5GET /module/{dataspace} (see issue #1)
Read all modules in the store for the given dataspace

Anchor Points persistence

6PUT /anchor-point/Json Object 

Create an anchor point given a name and a dataspace and module (namespace and revision)

7GET /anchor-point/{dataspace}/{name}/
Read an anchor point and the associated attributes given a name and a dataspace.
8DELETE /anchor-point/{dataspace}/{name}

Delete an anchor point given a name and a dataspace. (will delete whole tree)

9GET /anchor-point/{dataspace} (see isue#1)

Read all anchor points in the system given a dataspace.

10GET /module/{dataspace}/{anchor-point}/

Get a module (reference), given an anchor point 

11GET /anchor-point/fragment/{dataspace}/{xpath}/
Get the anchor point of a fragment given a fragments xpath

Fragment persistence

12PUT /fragment/{dataspace}/{name}/FileCreate a (root) fragment for a given anchor point, the fragment can have children.
13PUT /fragment/{parent-fragment-id}/FileCreate a fragment given an ID relative to the parent
14GET /fragment/{dataspace}/{name}/
Get a fragment given a anchor point (return just one level with just xpath references to its children)
15GET /fragment/{dataspace}/{xpath}/ (see isue#2)
Get a fragment given a Xpath expression 
16GET /fragments/{dataspace}/{anchor-point}/
Get all the fragments under an anchor point given a anchor point (notice similarity with /fragment/{dataspace}/{anchor-point}/  (just one letter!)
17GET /fragment/{dataspace}/schema-node-identifier/{schema-node-identifier}/
Get all the relevant fragments given a schema node identifier 
(not need to specify dataspace is schema-node-identifier is globally unique)

...