1. Pages
2. …
3. OIMT
4. IISOMI
5. IISOMI Minutes
6. 2021 IISOMI Minutes

2021-07-30 IISOMI Meeting Minutes

30 Jul 2021 Leader: Nigel Davis

06 Aug 2021 Leader: Andrea Mazzini

13 Aug 2021 Leader: Scott Mansfield (Not available: Andrea)

20 Aug 2021 Leader: Hing-Kam Lam (Not available: Nigel, Andrea)

27 Aug 2021 Cancelled (Not available: Nigel, Andrea, Italo)

03 Sep 2021 Leader: Nigel Davis (Not available: Bernd)

10 Sep 2021 Leader: Andrea Mazzini  (Not available: Bernd)

17 Sep 2021 Leader: Scott Mansfield

All

IISOMI Action Items review (every meeting)

Action item discussed:

• Nigel Davis 30 Jul 2021: Further updates on issue of "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."

Proposal

Independent of the issue of UML format comments in Yang, there appears to be a benefit in highlighting when a formal name is being used. Currently, there is no distinction between an informal usage of a word in a comment and use of the name of a yang structure that happens to be a single word (e.g., 'connection'). The same is true to a lesser extent for the UML model. Hence, the comments are in places ambiguous. It would seem beneficial for an editor to highlight when a word is being used as the name of a structure and when it is being used informally.

Ideally this would be enable by the tool using some in-typing control (such as "@" for names in a wiki with disambiguation where the string is used more than once. It is important that this is stored as a marked string and NOT an xmi id and that this marking is lightweight (e.g., a simple text character control (e.g., $$)). It is important that the method includes a metaclass identifier (e.g. $$c: for class).

Phasing:

1. 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.
2. Develop and use a light weight manual method (same format that tooling would eventually drive).
3. Develop UML-Yang tooling to be sensitive to the marking and to translate the format
4. Enhance Papyrus to enable incremental typing name validation

Note: The proposal to change the name format to be less rigorous is considered as a backward step. 

Martin suggested that we simply use tooling driven solution that post processes the Yang (and UML) to correct name formats etc. The challenge is with one name words.

• @Nigel Davis 03 Sep 2021 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  ).

LoreLei Rouvrais

Nigel Davis

Martin Skorupski

2021-07-23 O-RAN Alliance is looking for tooling and may also be able to fund the work on tooling.
Created a small "Tooling Coordination Team" that produced a slide set "WG10 Tooling proposal" on that topic.

Martin presented the slide set:

• Input from various SDOs into the O-RAN information model (written in Papyrus) which is the "single source of truth"
• Use Gendoc to create pdf-version of the information model
• Need to create an O-RAN YANG specification which need to be able to import also existing YANG specifications from other SDOs
• Not clear if re-engineering of existing YANG specifications to UML is required by O-RAN; e.g., 3GPP is not using Papyrus
• See also Project proposal for UML-To-YANG
  • Goal: Complete tool supported project lifecycle
• O-RAN is using Papyrus 2020-06 with the latest profiles
• O-RAN wants to harmonize terminology/semantic among their teams using UML
• UML model validation is required
• O-RAN will provide 4 interfaces
• Preferred is a Linux Foundation project that works on the tools
• IISOMI Guidelines shall be used
• Need to estimate the effort that is required for the tooling (may need to rewrite the mapping tool from scratch because a complete restructuring is necessary)

Further discussion next week when Scott is available

2021-07-30

Martin gave a brief summary of ORAN tooling proposal.

Scott emphasized that the current tooling should not be a base. 

The UML-Yang guidelines need to be rationalized to construct a master version of the document (there are several versions). This version should be reviewed to validate that it is complete/up to date. It is expected that the guidelines are essentially complete. There should be a futures section to cover:

• When statements etc.
• X-path
• Rules with OCL
• Comment statement massage 

The prioritization of tooling work needs to be agreed.  Need to capture the additions to guidelines that are necessary for the current published Yang.

Conditional mandatory is complex and tooling support would be highly beneficial.

• Hing-Kam Lam 20 Aug 2021 At the meeting, review ORAN tooling funding status to enable planning for key activities related to guidelines etc. to enable new tooling to be constructed.

There have also been request to start with Yang convert to UML then return to Yang (round trip). It was agreed that the starting point of any round trip must be UML. The UML-Yang mapping is lossy. All aspects of the UML model not in the Yang result would need to be captured and retained (in some form of supporting metadata/model format) with the Yang such that a tool that took the reverse path of the round trip (Yang to UML) could combine the Yang and supporting metadata and produce the original UML.

Editor's note:

• In principle, a yang model and supporting metadata could be constructed and run through the  Yang to UML tool to construct UML conformant with the guidelines.
• Clearly diagrams would be a challenge

May 14: 2021-05-14 IISOMI Meeting notes  

Scott Mansfield presented the Model2Doc feature from Papyrus

• still in pre-release state
• need to install Model2Doc tool integrated into Eclipse 2021-03 (nightly build) and Papyrus 5.1 (nightly) and Model2Doc (0.8.0 nightly)
• requires Java version greater than 11
• creates Word files
• need to check if Model2Doc provides at least the functionality of Gendoc
• Gendoc does not work with newer Papyrus versions (see below)
  
• Further investigation is required
• Work continues to create a model2doc template that produces the same material as the gendoc template (class/attribute/datatype/stereotype etc.)

All
Hing-Kam Lam

May 14: 2021-05-14 IISOMI Meeting notes

• GenDoc didn't generate constraint
• GenDoc didn't generate the Interface definitions
• GenDoc didn't generate the Type of pointed external (imported) classes
• GenDoc OstigOTtpSource::txti:EByte multiplicity [64] is not generated correctly
• AI (5/28/2021): Scott Mansfield11 Jun 2021 to look at all GenDoc issues above and try to find solutions

May 28:  2021-05-28 IISOMI Meeting notes

• Discussed possible output formats of interfaces/operations.

July 23: No discussion

July 30: No discussion