Problem Statement:

Need to provide guidlines for coding the Target path of the «Specify» relationship.

2022-05-27 IISOMI Meeting Minutes

• Remaining issue
  • Italo's second question "Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option?"

• • Only briefly discussed. No definitive conclusion yet.
  • It seems that in UML it should be the module name, and the mapping tool will then maps the module name to the module prefix. 

2022-02-04:

• Bernd shared his off-line email discussion with Andrea on how to improve the explanation in section 5.4.3/TR514. 
  • In his off-line discussion, Bernd raised a question on second part (yellow highlighted) of the path.
  • 
• No conclusion reached from the long discussion. Will continue the discusion in the next call.
• On Italo's second question "Should we use the module name (i.e., IetfPtp) or the module prefix (i.e., ptp) or either option?"
  •   Agree that in the UML model, the module name should be used because module prefix is a YANG term.

Post call email from Italo:

• RE_ IISOMI_ Action Item on Specify target path.msg

2022-02-11:

In order to be able to compose the target path of the two «Specify» relationships the class diagram below has been extended with the greyed out "non existing" object class and composition relationships.

Andrea Mazzini will draft rules for the UML Modelling Guidelines for creating the target paths; this is part of the existing action item "Improve explanation of target sterotype string content formation in the UML Guidelines". Discussion will continue in two weeks.

2022-03-04:

Italo Busi presents an UML diagram with abstraction examples and related translations into Yang augment statements.

• The following cases are considered:
  • augment <--> simple composition (one additional node in the tree)
    
  • augment <--> extendend composition (no additional node in the tree)
• Another reference is the email "Augmentation issues with UML2YANG" of 18 Feb 2022 by Italo Busi
• Clarified that the root of a Yang tree could also be a leaf or a list, besides a container.
• Clarified that the Yang augment statement applies when elements are distributed across different Yang modules.
• Italo Busi proposes to set as abstract the augmenting class in case the container is not required.
• Andrea Mazzini currently in TAPI UML the translation always leads to a container, e.g. the odu-connectivity-service-end-point-spec:

 augment "/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/tapi-connectivity:end-point" {
     container odu-connectivity-service-end-point-spec {
         uses odu-connectivity-service-end-point-spec;
         description "none";
     }
     description "none";
 }

Which is then an additional node in the Yang tree:

  +--rw context
     | ...
     +--rw tapi-connectivity:connectivity-context
     |  +--rw tapi-connectivity:connectivity-service* [uuid]
     |  | ...
     |  |  +--rw tapi-connectivity:end-point* [local-id]
     |  |  | ...
     |  |  |  +--rw tapi-odu:odu-connectivity-service-end-point-spec
     |  |  |  |  +--rw tapi-odu:odu-csep-common-pac
     |  |  |  |  |  +--rw tapi-odu:odu-type?                  odu-type
     |  |  |  |  |  +--rw tapi-odu:odu-rate?                  uint64
     |  |  |  |  |  +--rw tapi-odu:opu-tributary-slot-size?   odu-slot-size
     |  |  |  |  +--rw tapi-odu:odu-csep-ctp-pac
     |  |  |  |  |  +--rw tapi-odu:tributary-port-number?   uint64
     |  |  |  |  |  +--rw tapi-odu:tributary-slot-list*     uint64
     |  |  |  |  +--rw tapi-odu:odu-csep-ttp-pac
     |  |  |  |     +--rw tapi-odu:configured-mapping-type?   mapping-type
     |  |  |  |     +--rw tapi-odu:configured-client-type?    tapi-dsr:digital-signal-type

Italo Busi highlights that current translation does not allow distinct labels for the container and for the used class. By always specifying as abstract the augmenting class we may allow both ways.

Post meeting note: Italo Busi provides the updated diagram with a summary of the agreements-

• Below the base model example:

• The tree, note the abstract ClassA which is not translated, and abstract ClassC which is forcedly translated by the "presence condition".

    +--rw root
       +--rw element* [element-key]
          +--rw element-key    string
          +--rw leaf-1?        string
          +--rw leaf-2?        string
          +--rw leaf-a-1?      string
          +--rw leaf-a-2?      string
          +--rw container-b
          |  +--rw leaf-b-1?   string
          |  +--rw leaf-b-2?   string
          +--rw container-c!
          |  +--rw leaf-c-1?   string
          |  +--rw leaf-c-2?   string
          +--rw list-d* [key-d]
             +--rw key-d       string
             +--rw leaf-d-1?   string
             +--rw leaf-d-2?   string
  
  

• The schema:

module base-model-example {
  yang-version 1.1;
  namespace "urn:test:base-model-example";
  prefix b;

  grouping model-root {
    list element {
      key element-key;
      uses model-element;
    }
  }

  grouping model-element {
    leaf element-key {
      type string;
    }
    leaf leaf-1 {
      type string;
    }
    leaf leaf-2 {
      type string;
    }
    uses class-a;
    container container-b {
      uses class-b;
    }
    container container-c {
      presence
        "Presence condition";
      uses class-c;
    }
    list list-d {
      key key-d;
      uses class-d;
    }
  }
  
  grouping class-a {
    leaf leaf-a-1 {
      type string;
    }
    leaf leaf-a-2 {
      type string;
    }
  }

  grouping class-b {
    leaf leaf-b-1 {
      type string;
    }
    leaf leaf-b-2 {
      type string;
    }
  }

  grouping class-c {
    leaf leaf-c-1 {
      type string;
    }
    leaf leaf-c-2 {
      type string;
    }
  }

  grouping class-d {
    leaf key-d {
      type string;
    }
    leaf leaf-d-1 {
      type string;
    }
    leaf leaf-d-2 {
      type string;
    }
  }

  container root {
    uses model-root;
  }
}

• Below the augment model example:

• The tree:

  augment /b:root/b:element:
    +--rw leaf-a-1?   string
    +--rw leaf-a-2?   string
  augment /b:root/b:element:
    +--rw class-b
       +--rw leaf-b-1?   string
       +--rw leaf-b-2?   string
  augment /b:root/b:element:
    +--rw container-c!
       +--rw leaf-c-1?   string
       +--rw leaf-c-2?   string
  augment /b:root/b:element:
    +--rw list-d* [key-d]
       +--rw key-d       string
       +--rw leaf-d-1?   string
       +--rw leaf-d-2?   string

• The full tree:

    +--rw root
       +--rw element* [element-key]
          +--rw element-key      string
          +--rw leaf-1?          string
          +--rw leaf-2?          string
          +--rw leaf-a-1?        string
          +--rw leaf-a-2?        string
          +--rw container-b
          |  +--rw leaf-b-1?   string
          |  +--rw leaf-b-2?   string
          +--rw container-c!
          |  +--rw leaf-c-1?   string
          |  +--rw leaf-c-2?   string
          +--rw list-d* [key-d]
          |  +--rw key-d       string
          |  +--rw leaf-d-1?   string
          |  +--rw leaf-d-2?   string
          +--rw a:leaf-a-1?      string
          +--rw a:leaf-a-2?      string
          +--rw a:class-b
          |  +--rw a:leaf-b-1?   string
          |  +--rw a:leaf-b-2?   string
          +--rw a:container-c!
          |  +--rw a:leaf-c-1?   string
          |  +--rw a:leaf-c-2?   string
          +--rw a:list-d* [key-d]
             +--rw a:key-d       string
             +--rw a:leaf-d-1?   string
             +--rw a:leaf-d-2?   string

• The schema:

module augment-model-example {
  yang-version 1.1;
  namespace "urn:test:augment-model-example";
  prefix a;

  import base-model-example {
    prefix "b";
  }

  grouping class-a {
    leaf leaf-a-1 {
      type string;
    }
    leaf leaf-a-2 {
      type string;
    }
  }

  grouping class-b {
    leaf leaf-b-1 {
      type string;
    }
    leaf leaf-b-2 {
      type string;
    }
  }

  grouping class-c {
    container container-c {
      presence
        "Presence condition";
      uses class-c-pac;
    }
  }

  grouping class-c-pac {
    leaf leaf-c-1 {
      type string;
    }
    leaf leaf-c-2 {
      type string;
    }
  }

  grouping class-d {
    leaf key-d {
      type string;
    }
    leaf leaf-d-1 {
      type string;
    }
    leaf leaf-d-2 {
      type string;
    }
  }

  augment "/b:root/b:element" {
    uses class-a;
  }

  augment "/b:root/b:element" {
    container class-b {
      uses class-b;
    }
  }

  augment "/b:root/b:element" {
    uses class-c;
  }

  augment "/b:root/b:element" {
    list list-d {
      key key-d;
      uses class-d;
    }
  }
}

2022-03-25:

Italo Busi 22 Apr 2022  Italo to provide an update to the diagram and propose text for the mapping guidelines.

2022-06-17 IISOMI Meeting Minutes

• Italo presented his proposals of updating the guideline documents. See the next roll of this minutes. Due to short of time, the discussion will continue in the July 1 IISOMI call.

2022-07-01 IISOMI Meeting Minutes

• Italo Busi 01 Jul 2022 Coding of target path: Provide an update to the diagram and propose text for the mapping guidelines. (see Coding of target path)
  • Figure 5.30 in <Draft_TR-514_UML_Modeling_Guidelines_v1.3.04 - ib-00.docx> from Italo's 13 May 2022 email to BZ, AM, & KL
  • 
  • Clarification made in the discussion
    • The OMG UML abstraction: When there is the abstraction dependency between ClassA and ClassB, attributes of ClassB will be instantiated in instance of ClassA, instead of in instance of ClassB. But there could be instance of ClassB instantiated independent of ClassA. This is why ClassB needs not to be an abstract class. 
    • The IISOMI «Specify»: ClassB is abstract class. Never have ClassB instance.
    • Difference between «Specify» and «ExtendedComposite»: «Specify» has a path, which allows inter-module referencing. «ExtendedComposite» doesn't have a path and is used for classes within the same module. So, for classes within the same module, no need to use «Specify».
      • Question: Should «Specify» be used for classes between Aggregates, even the Aggregates are within the same module?
  • Will continue the discussion in the next call.

2022-07-15 IISOMI Meeting Minutes

References

• • IISOMI Action Items: Italo Busi 01 Jul 2022 Coding of target path: Provide an update to the diagram and propose text for the mapping guidelines. (see Coding of target path)
  • IISOMI Discussions: Coding of target path

Discussion: 15 Jul 2022 

• • Discuss and recap the inconsistency among the following 3 specifications related to the «Specify» stereotype:
    • In the UML Guideline, Figure 5.30: ClassB must be abstract. 
    • In TAPI, ClassB is concrete
    • In the UML2YANG Guideline, in some diagrams the class is abstract, but the text implies concrete (container). 
  • How to resolve the inconsistency?
    • Remain open.
      • Need to evaluate the impact on TAPI if it is going to follow the UML Guideline.
      • Need to investigate the impact on the behaviour of the different forks of the mapping tools.