Nigel Davis Review proposal for "UML comments often include construct name formatted according to the UML guidelines. When the UML is converted to Yang the construct names are then incorrectly formatted." (in minutes 2021-07-30 IISOMI Meeting Minutes).
Current state: The Yang has UML formatted names in it. The user is required to simply deal with this. There have not been any specific complaints, but clearly the comments are confusing. It may be beneficial to add notes to the read-me or similar to explain the formatting transition.
"The 'description' text often includes names of properties, classes etc. that are in 'camel case' as opposed to 'hyphen-case'as used for yang labels. The names can be converted by simply ensuring the first letter is lower case and that any intermediate upper case letters are turned into lower case preceeded by a hyphen (e.g., HyphenCase → hyphen-case)."
Scott MansfieldTo take the gendoc examples from the guidelines and perform regression test.
Work progressing
Scott MansfieldTo take the gendoc examples from the guidelines and perform regression test.
Scott Mansfield To investigate why none of the <<cond>> is retrieved from the model.
Andrea indicated the had attempted to apply analogous rules to member-end to include other properties. Andrea tried various techniques to get client and supplier but with no success
Probably need to review the UML metadata
Andrea was able to print the target string
Scott Mansfield To investigate how to get client and server values for an abstraction.
Italo BusiTo verify and confirm that an "Extended composition" can also be used with Interfaces and Signals.
One extension class can be used to extend multiple base classes.
This is useful when considering Yang
Modeling guidelines force no operations in object classes and no attributes in interfaces
Italo discussed the ITU-T structure below
Bernd noted that there was no discussion on interfaces extending object classes. Bernd agreed that he would consider this during the update of guidelines.
Italo indicated that this is done by uses
Scott noted that the extension with notifications should be via an augment so an application could leave it out. if-feature may also be useful.
Italo noted that as the ITU-T usage is in the same model it is not an augment.
Nigel noted that the decision had been made to separate operations from object classes as the target was intent based interactions where there is no direct operation on an object. Bernd also noted that there is a to separate static and dynamic.
Italo noted that signal should also be considered
It was agreed that interface and signal could both extend object classes but object classes cannot extend signal or interface.
Bernd Zeuner Update modeling guidelines with "interface and signal can both extend object classes but object classes cannot extend signal or interface."
Bernd ZeunerDraft an example Wiki page that capture an discussion item
Bernd explained a discussion items page
The minute taker should copy the text from the minute into relevant pages of the wiki
Scott asked why we are not using Jira
Does ONF have a Jira license.
Scott also noted that there was a discussion on use of github for git issues.
If we need a better action tracking system, we should use Jira.
It was agreed that the current technique leaves the actions smeared and repeated across the minutes.
Use of git may be problematic as we have multiple repositories.
Nigel Davis determine whether ONF can create IISOMI Jira.
Bernd proposed to capture the discussion items in GitHub Issues than in the IISOMI Meeting Minutes and just provide a link to the GitHubIssue in the minutes. This prevents that the same discussion minutes appear many times in the minutes. Two draft Issues are contained inhttps://github.com/samans/iisomi-private/issues/1andhttps://github.com/samans/iisomi-private/issues/2and have been presented at the meeting.
At the discussion it was pointed out that
a private repository is not the appropriate place for the items since not everyone has access to this
the ONF GitHub is publicly available but not all participants are allowed to contribute to it
there is no single ONF repository which could host such Issues; IISOMI is spread over many repositories
it might be possible to cover the discussions in Wiki pages
new discussions should be captured in the Meeting Minutes and then copied to the Wiki pages
Bernd ZeunerDraft an example Wiki page that capture an discussion item
Andrea highlighted the need to use yang feature/condition capabilities. MEF are planning on introducing updates to TAPI to allow isolation of specific MEF relevant parts.
There was a brief related non-IISOMI discussion on interworking between ONF TAPI and MEF.
There is a need for tooling support.
September 24, October 1:No discussion
4
10 min
Extended composition in UML (including object classes and interfaces)
Mentioning of UML artefact names (UCC) in YANG descriptions creates problems. E.g., TerminationPoint (object class) is converted in YANG to termination-point (statement) but if "TerminationPoint" appears in the related YANG description it is remains TerminationPoint.
Agreement:The Mapping Tool should convert also the artefact names within the descriptions to YANG style (i.e.,kebab-case). The list of names to be converted in the descriptions is limited to the UML artefact names.
Bernd ZeunerUpdate the Mapping Guidelines with a rule thatartefact names within the descriptions should be converted to YANG style.
Scott Mansfield created reengineer-private Github repository and added the reengineered IEEE and IETF YANG models from Februrary 12, 2020 to it. People interested can askScott Mansfieldfor the access.
9
Cleanup of the existing public GitHub (ONF EAGLE), rationalize the forks/branches
September 24:Scott Mansfieldclarifies thatwithout the involvement of key folks with authority on Github no progress can be performed. No administrators appear for ONF EAGLE Github.
Gendoc output for Interfaces, Operations, Associations, Abstractions
How to dump endpoints of abstractions?
Italo BusiDump of Realizations possible? Andrea MazziniGiven thatInterface Realizationsare dumped asAbstractions, maybe this is valid also forRealizations.
