You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »


Assumptions

#Description
1Yang namespaces are globally unique (except for multiple revisions)

Open Issues/Decisions

#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

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)








  • No labels