Child pages
  • 2022-11-18 IISOMI Meeting Minutes
Skip to end of metadata
Go to start of metadata





  • Administrative
    • Call plan (schedule, leader)
  • Action Item Review
  • Updates to gendoc data dictionary
  • Questions to Italo: Modelling Guidelines - Comment on Figure 5.30? - Figure 5.31 fixed? - Example 2   * Are the PruneAndRefactor relationships necessary for the example?   * The «StrictComposite» stereotype is obsolete. Mapping Guidelines - MainModel <-> MainModule? - Table 5.17 Entity/Specification: RootElement?
  • AOB

Discussion items





5 minAdmin: Call planAll

 Leader: Nigel; (Not available: n/a)

 Leader: Bernd; (Not available: Scott)

 Leader: Kam; (Not available: Bernd)

 Leader: Scott; (Not available: Italo)

 Leader: Nigel; (Not available: Scott)



 Leader: Bernd; (Not available: Italo)

3 minAction items due/doneAll

IISOMI Action Items done or past due

  • Nigel Davis  Provide Bernd with ONF Style converted script from Scott related to associations (See action from 2022-08-12).
  • Changed Bernd's action to be due a week after Nigel's action.
  • Nigel Davis stated that he had not had an opportunity to complete his action. The action was moved to  
10 minItalo's requestScott

Add a section to print out abstractions

Note that the following has been added to Abstractions: How to dump the properties

specify with target string and specify with condition

Add IsLeaf to an enumeration

Print the constraint between the relationship from within the referenced context.

Note that the following has been added to Publishing constraints using gendoc

Tool may be complex and hence best to not put in object class.

Constraint should be in a separate section.

Reference to context from within the constraint.

It was noted that there is no guideline for the name of a constraint. It was concluded that this should be UpperCamel case (as currently defined for xor).

Bernd Zeuner Generalize the rule on naming of constraints (currently only mentions xor)

40 min

Italo's request

Note that the discussion below has been added to «Specify» relationship

It was noted that the statement above indicates that the augmenting class must be abstract.

The tooling and the UML-YANG guidelines indicate that the augmenting class can be concrete.

TAPI uses concrete augmenting class.

Italo has a problem with this in the example below.

In the example above it is not clear how the specify relationship was formed.

In the above example, if TopologyContext was abstract the _topology attribute would appear in TapiContext in the instance.

The figure below is not correct as the augmenting class is concrete.

Two choices:

  • mandate abstract class (implications on TAPI)
  • allow (and explain) both concrete and abstract (depending upon the rules, this may still have implications for TAPI)

Bernd Zeuner Regarding concrete v abstract augmenting class, provide figures to support further discussion and decision.

Also discussed:

Italo confirmed that this was now covered.


Note that the discussion below has been added to Root element issues

Bernd questioned whether this should be MainModel or MainModule.

Note that the discussion below has been added to «Specify» relationship

Agreed that the use of model/module is just a a string and does not need to be translated by the tool.

The above diagram is not correct as it implies that the target must be a root element but it is not shown as such. As any class can be augmented the diagram should be generalized to show a partial string in the target such as /xxx/ etc.

Bernd Zeuner redraw/clarify various figures as clarified above 

X minAOB