Preparing for RTD deployment.

Author: datadavev

source/design/UseCases/01_uc.txt

@@ -10,7 +10,7 @@ Goal
 
 Retrieve an object identified by PID.
 
-Summary 
+Summary
 ~~~~~~~
 
 A client has an identifier for some object within the DataONE system and is
@@ -19,10 +19,10 @@ Coordinating Node). If the object exists on the node and the user has READ
 permission on the object, then the bytes of that object are returned,
 otherwise an error condition occurs.
 
-This low level operation assumes that the client knows that the desired object 
-is available on the target node. The normal process for retrieving an object 
-given only the identifier is to first resolve the object, then retrieve the 
-object from one of the identified nodes. Resolution is described in 
+This low level operation assumes that the client knows that the desired object
+is available on the target node. The normal process for retrieving an object
+given only the identifier is to first resolve the object, then retrieve the
+object from one of the identified nodes. Resolution is described in
 :doc:`UC36 </design/UseCases/36_uc>`.
 
 Actors
@@ -55,12 +55,13 @@ Post Conditions
 
 
 .. uml::
+   :alt: Use case 01 diagram.
 
    @startuml images/01_uc.png
    actor "User" as client
    usecase "12. Authentication" as authen
    note top of authen
-   Authentication may be provided 
+   Authentication may be provided
    by an external service
    end note
 
@@ -87,9 +88,6 @@ Post Conditions
 action.
 
 
-.. image:: images/01_seq.png
-
-
 .. uml::
 
    @startuml images/01_seq.png
@@ -119,7 +117,6 @@ distinction is made between Member Node and Coordinating Node implementation
 as they are identical at this level of detail.
 
 
-
 **Notes**
 
 1. For the GET operation, should isAuth() be performed only by CNs? Relying on

source/design/UseCases/03_uc.txt

@@ -11,7 +11,7 @@ Revisions
 Goal
   Register a new Member Node.
 
-Summary 
+Summary
   This use case describes the technical process for addition of a new member
   node (MN) to to the DataONE infrastructure. It is assumed that the
   appropriate social contracts have been formed and the MN is operational,
@@ -40,14 +40,14 @@ Triggers
   - A new Member Node is ready to be brought online and a DataONE
     administrator initiates the process.
 
-Post Conditions 
+Post Conditions
   - The new MN operates as part of the DataONE infrastructure
 
   - DataONE infrastructure resources are incremented by the amount available
     at the new MN
 
   - The operation outcomes are logged
-  
+
   - Synchronization of the MN commences as per scheduled operation
 
   - Synchronize capabilities metadata across CNs
@@ -56,68 +56,35 @@ Post Conditions
 
   - The new MN is added to CN list of targets for replication
 
-**Notes**
 
-- Specify default replication policies
-
-- Also check for version updates
 
-- Should new nodes be registered with specified trust levels?
-
-- Are there different levels of trust for member nodes? 
-
-- Data providers that use acceptable services can still be discovered and
-  accessed without registering in the DataONE registry (Conflicting, as
-  someone has to register it). 
-
-  However, a MN that has not registered but does expose DataONE services is
-  not part of the DataONE infrastructure and so does not participate in
-  replication or other DataONE services.
-
-- Allow service providers to register their services, (such as data extraction
-  services) (ala GEOSS), but include mapping to higher semantic model
+.. uml::
 
-- For well known services, registration system must be able to describe
-  constraints (e.g., allowable inputs, outputs, algorithms that can be
-  specified)
+   @startuml images/03_uc.png
 
-- Services can be parameterized
+   actor "User" as client
+   usecase "12. Authentication" as authen
 
-- Member node should be able to request the coordinating node to re-validate
-  its capabilities list.
+   actor "Administrator" as admin
+   admin ..|> client
+   actor "Coordinating Node" as CN
+   actor "Member Node" as MN
+   usecase "13. Authorization" as author
+   usecase "03. Register MN" as register
+   admin -- register
+   CN -- register
+   MN -- register
+   register ..> author: <<includes>>
+   register ..> authen: <<includes>>
 
-.. image:: images/03_uc.png
+   @enduml
 
 *Figure 1.* Use Case 03.
 
 
-.. image:: images/03_seq.png
-
-*Figure 2.* Interactions for use case 03.
-
 
-..
-   @startuml images/03_uc.png
-   
-   actor "User" as client
-   usecase "12. Authentication" as authen
+.. uml::
 
-   package "DataONE"
-     actor "Administrator" as admin
-     admin ..|> client
-     actor "Coordinating Node" as CN
-     actor "Member Node" as MN
-     usecase "13. Authorization" as author
-     usecase "03. Register MN" as register
-     admin -- register
-     CN -- register
-     MN -- register
-     register ..> author: <<includes>>
-     register ..> authen: <<includes>>
-   @enduml
-
-
-.. 
    @startuml images/03_seq.png
    actor Admin
    participant "Admin" as app_admin << Application >>
@@ -140,11 +107,44 @@ Post Conditions
    c_reg -> c_sync: scheduleSynch ()
    note right
     Harvest process occurs asynchronously.
-    Separate use case. 
+    Separate use case.
    end note
    app_admin <-- c_reg: ack or fail
    deactivate c_reg
    @enduml
 
+*Figure 2.* Sequence diagram for use case 03.
+
+
+**Notes**
+
+- Specify default replication policies
+
+- Also check for version updates
+
+- Should new nodes be registered with specified trust levels?
+
+- Are there different levels of trust for member nodes?
+
+- Data providers that use acceptable services can still be discovered and
+  accessed without registering in the DataONE registry (Conflicting, as
+  someone has to register it).
+
+  However, a MN that has not registered but does expose DataONE services is
+  not part of the DataONE infrastructure and so does not participate in
+  replication or other DataONE services.
+
+- Allow service providers to register their services, (such as data extraction
+  services) (ala GEOSS), but include mapping to higher semantic model
+
+- For well known services, registration system must be able to describe
+  constraints (e.g., allowable inputs, outputs, algorithms that can be
+  specified)
+
+- Services can be parameterized
+
+- Member node should be able to request the coordinating node to re-validate
+  its capabilities list.
+
 
 .. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/03_uc.txt

source/design/UseCases/04_uc.txt

@@ -33,85 +33,62 @@ Summary
 
 Actors
   Member Node, additional Member Nodes, Coordinating Nodes
-  
-  
+
+
 Preconditions
   - Use is authenticated and so client application has an auth_token for the process.
 
   - DataONE system operational
-  
+
   - MN is registered and is monitored
-  
-  
+
+
 Triggers
   - New data package is present on Member Node
-  
+
   - An existing data package is modified on a Member Node
-  
+
   - A data package is deleted from a Member Node
- 
- 
+
+
 Post Conditions
   - New data package is replicated across MNs
-  
+
   - Search metadata is updated
-  
+
   - Operation recorded in logs
 
   - CN update of search metadata
 
-  - CN replication of metadata 
+  - CN replication of metadata
 
   - Watchers notified of change
 
 
-**Notes**
-
-- Are IDs are pegged to versions? If so, update might differ more radically
-  from create.
-
-- If delete is a metadata operation only, then will be very similar to update.
-  But if it is a physical operation, it becomes more complex. Will there be an
-  archival copy? Will member nodes that hold replicas be "forced" to destroy
-  the replicas?
-
-- Is submit from a member node a push or pull?
 
-- Should queuing of a submission within a member node be required for success?
-  (We assume yes, to guarantee replication of submissions).
+.. uml::
 
-- Can data packages be deleted or modified?
+   @startuml images/04_uc.png
+   actor "User" as client
+   usecase "12. Authentication" as authen
 
-.. image:: images/04_uc.png
+   actor "Coordinating Node" as CN
+   actor "Member Node" as MN
+   usecase "13. Authorization" as author
+   usecase "04. Create Object" as create
+   usecase "06. MN Synchronize" as mn_sync
+   client -- create
+   CN -- create
+   MN -- create
+   create ..> author: <<includes>>
+   create ..> authen: <<includes>>
+   create ..> mn_sync: <<includes>>
+   @enduml
 
 *Figure 1.* Use case 04.
 
-.. image:: images/04_seq.png
+.. uml::
 
-*Figure 2.* Create, update, delete, science metadata or data object in Member 
-Node.
-
-.. 
-   @startuml images/04_uc.png
-   actor "User" as client
-   usecase "12. Authentication" as authen
-
-   package "DataONE"
-     actor "Coordinating Node" as CN
-     actor "Member Node" as MN
-     usecase "13. Authorization" as author
-     usecase "04. Create Object" as create
-     usecase "06. MN Synchronize" as mn_sync
-     client -- create
-     CN -- create
-     MN -- create
-     create ..> author: <<includes>>
-     create ..> authen: <<includes>>
-     create ..> mn_sync: <<includes>>
-   @enduml        
-
-
-.. 
    @startuml images/04_seq.png
    Actor User
    participant "Client" as app_client << Application >>
@@ -135,5 +112,28 @@ Node.
    deactivate c_health
    @enduml
 
-.. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/04_uc.txt
 
+*Figure 2.* Create, update, delete, science metadata or data object in Member
+Node.
+
+
+**Notes**
+
+- Are IDs are pegged to versions? If so, update might differ more radically
+  from create.
+
+- If delete is a metadata operation only, then will be very similar to update.
+  But if it is a physical operation, it becomes more complex. Will there be an
+  archival copy? Will member nodes that hold replicas be "forced" to destroy
+  the replicas?
+
+- Is submit from a member node a push or pull?
+
+- Should queuing of a submission within a member node be required for success?
+  (We assume yes, to guarantee replication of submissions).
+
+- Can data packages be deleted or modified?
+
+
+
+.. _history: https://redmine.dataone.org/projects/d1/repository/changes/documents/Projects/cicore/architecture/api-documentation/source/design/UseCases/04_uc.txt