Child pages
  • 2021-07-30 IISOMI Meeting Minutes
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Date

Attendees

Apology

Agenda

  • Administrative
  • UML → YANG Mapping Tool update
    • O-RAN cooperation
    • Private GitHub
    • Cleanup of the existing public GitHub (ONF EAGLE), rationalize the forks/branches,
    • Identify different releases, Release management, and release plan; e.g., current ITU-T Q14/15 version and TAPI version are different 
    • How to merge the private GitHub development into the public GitHub (ONF EAGLE)
  • Convention of UML property names in document/comment/description
  • Gendoc output for Interfaces and Operations and Association
  • Papyrus-Model2Doc further investigations?
  • Papyrus 5.0.0 Version (202106)
  • Agenda of next call
  • AOB

Discussion items

#

Time

Item

Who

Notes

15 minAdmin: Call planAll

 Leader: Nigel Davis

 Leader: Andrea Mazzini

 Leader: Scott Mansfield (Not available: Andrea)

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

 Cancelled (Not available: Nigel, Andrea, Italo)

 Leader: Nigel Davis (Not available: Bernd)

 Leader: Andrea Mazzini  (Not available: Bernd)

 Leader: Scott Mansfield

25  min

Admin: IISOMI Action Items status

All

IISOMI Action Items review (every meeting)

Action item discussed:

  • Nigel Davis : 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  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  ).
350 min

UML → YANG Mapping Tool:
O-RAN interest and potential redevelopment support

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  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


4

Convention of UML property names in document/comment/description

KamNot discussed. Deferred to next call.
5

Gendoc output for Interfaces and Operations and Association

AllNot discussed. Deferred to next call.
6
Papyrus-Model2Doc feature

May 142021-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.)

GenDoc no longer work with Eclipse Papyrus 2020-06. 

May 282021-05-28 IISOMI Meeting notes

June 11: No discussion

July 9: No discussion

July 23: No discussion

July 30: No discussion

7
Papyrus 5.0.0 Version

June 11: No discussion

July 9: No discussion

July 23: No discussion

July 30: No discussion

8

GenDoc Issues

May 142021-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 Mansfield 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

9
Agenda of next callAll
  • Administrative
  • UML → YANG Mapping Tool update
    • O-RAN cooperation
    • Private GitHub
    • Cleanup of the existing public GitHub (ONF EAGLE), rationalize the forks/branches,
    • Identify different releases, Release management, and release plan; e.g., current ITU-T Q14/15 version and TAPI version are different 
    • How to merge the private GitHub development into the public GitHub (ONF EAGLE)
  • Convention of UML property names in document/comment/description
  • Gendoc output for Interfaces and Operations and Association
  • Papyrus-Model2Doc further investigations?
  • Papyrus 5.0.0 Version (202106)
  • Agenda of next call
  • AOB

Action items

  •  
  • No labels