Regarding abstract/concrete of the extending class in the «Specify» relationship: UML Modelling Guidelines only recommend to use abstract extending classes (whereas TAPI uses concrete extending classes); need to discuss this issue with TAPI.
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.
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 ZeunerRegarding concrete v abstract augmenting class, provide figures to support further discussion and decision.
Italo confirmed that this was now covered.
Bernd questioned whether this should be MainModel or MainModule.
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 On «Specify»,redraw/clarify various figures as noted above (related to... not only root class)
Agreement: two new actions created, one for Bernd to create a small model with both examples and update the powerpoint with the expected results, and the second action is for Scott to run the tool and determine how to support the "abstract" case (which is currently not supported).