PROLIST-ECLASS-Change-Management-Reference-Algorithm

PROLIST-ECLASS-Change Management Reference Algorithm supersedes the reference algorithm section of the PROLISt-ECLASS Change management rules document. Once a stable state is reached, it is meant to be included into version 2.0 of that document.

St– structure data of release

Tt – transaction data created at time t based on structure St

St+1 – structure data of release t+1

Tt+1 – transaction data created at time t based on structure St+1

For documents connected to a node (“local documents”), it can be assumed that these can in principle be traeated like values (without the need for a conversion), so whenever a copy_value is performed, all documents are copied to the target path of the found equivalent path. Global documents are copied to the successor of the device

If not overruled by a cardinality value set explicitly for a certain block via a fixed cardinality in structure or a value in the transaction, it must be assumed for application purposes that all blocks have cardinality = 1.

Not all equivalent_paths contained in the transaction update file end with a property at root node (see TU FFS Chapter 10.6 for an example). These paths to intermediate nodes serve for updating views an allow copying of documents which are not attached to the leaf properties.

EQUIVALENT_PATH(Pt, Pt+1, UNITS_MAP, VALUES_MAP)

• Commands defining how transaction paths are converted from source to target

DELETE_PATH(Pt)

• Commands defining the transaction paths that are suggested to be deleted

PROPOSE_VALUE(Pt+1, VALUE)

• Commands proposing values for some of the paths in target structure

SELECT_BRANCH(Pt+1)

• Commands helping the navigation in target structure and building the polymorphic structure. This command is a convenience command used to keep the reference algorithm simple but can be considered redundant because St+1 already contains all the information about polymorphism.

1. STEP - LOAD SOURCE: Load transaction data Tt using St
2. STEP - BUILD TARGET: Create empty transaction Tt+1 for the same device but in St+1
3. STEP – PUSH STRUCTURE: Traverse all nodes in Tt (depth search). For each path Pt:a. If Pt is valuating cardinality (e.g. “number of ….”)

   i. Pt+1 := find_equivalent_path(Pt)

   ii. If Pt+1 found =>
   • Value(Pt+1) := Value(Pt)
   • Update structure Tt+1 to reflect cardinality
   iii. Else if Pt+1 not found but DELETE exists (to be implemented LATER)
   • Inform user that new dictionary does not have property Pt. If Value(Pt) > 1 inform the user that the properties valuated as a consequence of the fact that cardinality is bigger than 1 are lost. Affected blocks needs to be calculated by the application processing the transactions and transaction update files.
   iv. Else
   • Throw exception (“No transaction update record for Pt”)
   b. If Pt is valuating “type of” property – polymorhismus

   i. Pt+1 := find_equivalent_path(Pt)

   ii. If Pt+1 found
   • Update structure Tt+1 to contain the branch of Tt
   • Value(Pt+1) := Value(Pt)
   iii. Else if Pt+1 not found but DELETE exists (to be implemented LATER – it is the case when polymorphic structure is replaced by reference properties)
   • Inform the user that “type of” property is not anymore existing
   iv. Else
   • Throw exception (“No transaction update record for Pt”)
4. STEP – POP DEFAULTS AND EXPAND: Traverse proposed values for Tt+1(depth search). For each path Pt+1:a. If Pt+1 is in SELECT_BRANCH commands

   i. Update the polymorphic structure below Pt+1 (select branch)

   b. default_value = find PROPOSE_VALUE (Pt+1)

   c. If Pt+1 is valuating cardinalityi. If default_value found
   • Value Pt+1 = default_value
   • Update structure Tt+1 to consider this value

   ii. Else Value Pt+1 = 0 (suppling additional updates this can be overwritten)

   d. Else if not valuation cardinality AND default_value found

   i. Value Pt+1 = default_value

5. STEP COPY_VALUES: Traverse all nodes in Tt (depth search). For each leaf path Pt:

   a. Pt+1 := find_equivalent_path(Pt)

   b. If Lt+1 found copy_value(P t ,P t+1 )

   c. else if Lt+1 is not found but DELETE exists (suggestion to delete the value)

   i. Application can delete the values

   d. else

   i. Throw exception (“No transaction update record for Pt”)

1. If Valid(Pt , St+1) => return Pt+1 (newest version of elements in St+1)
2. Lookup TU for EQUIVALENT_PATH(Pt)

   a. FOUND => return equivalent path

   b. NOT FOUND

   i. If ( found DELETE_PATH(Pt)) return VOID

   ii. Else return NOT_FOUND

Note: There is no compression (or folding) of EQUIVALENT_PATH commands. This means that for all relevant leaf node in source needs to be an EQUIVALENT_PATH in target.

1. Lookup tu = TU for EQUIVALENT_PATH(Pt)a. FOUND

   i. Copy document(s)

   ii. IS_NO_INTERMEDIATE_NODE
   1. PropertyDataTypeChangeda. Change in list of compatible changes
      • Convert value based on unit mapping, value mapping and original value, reflecting compatible type of data type change
      b. Change not in list of compatible changes
      • Application specific handling of copy value based on custom agreement allowed
   2. Property data type not changed
   • Convert value based on unit mapping, value mapping and original value
   b. NOT FOUND
   • return

Convert_value function is doing a value conversion based on value datatype, selected value, old unit and new unit

Compatible Changes of data type are defined as (exhaustive list):

• Integer to Real

• Integer to String