Merge pull request #16 from UlfBj/master

Service data model update

docs-gen/content/service_data_rule_set/basics.md

@@ -33,26 +33,12 @@ The general structure of how a microservice is represented in a HIM tree is show
 ![HIM microservice tree structure](/hierarchical_information_model/images/microservice_tree_structure.png?width=50pc)
 *Figure x. HIM microservice tree structure
 
-- The name of the procedure is the name of the node of one of the types `iprocedure` or `mprocedure`, see more about the types below.
+- The name of the procedure is the name of the node of the type `procedure`.
 - The input and output parameters are respectively represented by a  node of type `iostruct` that must have the names 'Input' and 'Output', respectively.
 - An input/output parameter is represented by a node of type `property` or `symlink`.
 
 Any Input/Output nodes, and their associated children, are only present if the procedure has at least one parameter of the respective Input/Output.
 
-## Node types iprocedure and mprocedure
-The typical pattern for invoking a procedure by a client is that the logic implementing the procedure is actuated, and this actuation is controlled by the procedure input parameters.
-In a multi-client environment there might also be a need for clients to monitor the state and outputs of a procedure that might be invoked by other clients.
-The procedure may not have exactly the same input and output parameters for these two cases.
-A call for monitoring of the procedure should not include input parameters that are used in controlling its actuation as the procedure in this case is not actuated.
-The output may also contain other parameters for improving the observability of its state than when it is called for actuation of it.
-
-To realize these different cases, two different node types representing the procedure exist, the iprocedure (invoke procedure) node type and the mprocedure (monitor procedure) node type.
-The node names of these two nodes shall have the same procedure name, prefixed with "i" for the iprocedure node type and "m" for the mprocedure node type.
-The iprocedure node type MUST be defined for a procedure, the mprocedure node type MUST NOT be defined if there is not also an iprocedure definition.
-
-An interface implementing the HIM service data model is expected to support the two flavors of procedure calls.
-It may choose to support only the invoke flavor.
-
 ## Microservice completion state
 
 A microservice may have a significant temporal duration from it is started and until it completes.
@@ -61,6 +47,8 @@ as e. g. it may be the case that an ongoing microservice execution does not allo
 If an observable microservice completion state is desired, then the designer of this HIM service domain must create such an output parameter of the microservice.
 The characteristics of this output parameter can be freely chosen, but below is a proposal that if widely used may help to improve interoperability.
 
+The parameter shall be named Completion.
+
 The completion state of the HIM microservice is represented by a uint8 datatype value.
 
 The allowed values of the microservice state are:

docs-gen/content/service_data_rule_set/iostruct.md

@@ -25,7 +25,7 @@ Besides the mandatory metadata mentioned above, the following optional metadata
 For more information, please see the [Common Rule Set: Optional Metadata](/hierarchical_information_model/common_rule_set/basics#optional-metadata).
 
 - A leaf node cannot have the `iostruct` node type.
-- A parent must be of one of the node types `iprocedure` or `mprocedure`.
+- A parent must be of the node type `procedure`.
 - Children must be of the node types `property` or `symlink`.
 - It must have at least one child.
 

docs-gen/content/service_data_rule_set/procedure.md

@@ -0,0 +1,26 @@
+---
+title: "procedure node"
+weight: 30
+---
+
+The `procedure` node type must have the following mandatory metadata:
+- Name
+- Type
+- Description
+
+For more information, see the [Common Rule Set: Mandatory Metadata](/hierarchical_information_model/common_rule_set/basics#mandatory-metadata).
+
+Besides the mandatory metadata mentioned above, the following optional metadata may be used
+- Comment
+
+For more information, please see the [Common Rule Set: Optional Metadata](/hierarchical_information_model/common_rule_set/basics#optional-metadata).
+
+- A parent must be of the node type `branch`.
+- Children, if any, must be of the node type `iostruct`.
+
+An example of the specification of a `procedure` node is given below.
+```YAML
+microserviceName:
+  type: procedure
+  description: This is an example of a microservice procedure node containing its mandatory metadata.
+```