Ecore is used for the Modelica metamodel in Part III rather than EMOF (EMOF is also supported by the EMF technology). Oddly though I can see no depiction of the metamodel in either ecore or EMOF: I would for example expect to see some UML class diagrams. Instead there is what appears to be Modelica syntax.

The abstract syntax of Modelica, in other words its metamodel, needs to be represented in UML class diagrams. Figure 13 containing a representation of some Modelica metaclasses in an Ecore diagram will be replaced by UML class diagrams.

Source: Georgia Institute of Technology (Mr. Axel Reichwein, axel.reichwein(at)me.gatech.edu)
Summary: The QVT code shown in Annex C is incomplete. In addition, a figure showing an overview of the QVT implementation approach would be useful.

The QVT code in Annex C is outdated and has to be replaced by the latest
version. Since the current QVT code consists of approx. 5000 lines of code, it
would be too large to be placed in Annex C. Instead, Annex C should contain a
URL reference to a separate document containing all QVT transformations in a
zipped file. In addition, a figure showing an overview of the QVT implementation
approach should be placed in Annex C.

Not sure of the use of openmodelica.org.

Issues 16384 and 16385 address the correctness of using non-normative URIs to
identify the UML and Modelica metaclasses in the QVT transformation. The
implementation of the transformation in QVT includes references to the
metaclasses of both the UML and Modelica metamodels. These references are
found next to the “modeltype” keyword at the beginning of each QVT
transformation.
Since no normative Modelica metamodel exists, there are no normative URIs to
identify the Modelica metaclasses. The QVT code can thus not refer to Modelica
metaclasses through normative URIs and be considered normative. The use of
non-normative URIs to identify the UML and Modelica metaclasses in the QVT
transformation is therefore acceptable.
The QVT code does not need to be changed. However, the SysML-Modelica
Transformation specification should not state that Parts III, IV and V of the
SysML-Modelica Transformation specification are normative since they are all
based on a non-normative Modelica metamodel from openModelica.

Section 2 Conformance requires more detail for the practical definition of ‘full realization’ and ‘abstract syntax compliance’

Proposed change: leave out ‘full realization’ and ‘abstract syntax compliance’. In
addition, add a level 1 criteria referring to required level 0 compliance.

The UML Profile is represented in proprietary Eclipse format

The SysML4Modelica has been converted into OMG-grade XMI and has been added to the inventory of files which still includes the profile in Eclipse format.
Disposition:Resolved

As found by Lenny Delligatti of Lockheed Martin.

On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

See issue 16545 for disposition

As found by Lenny Delligatti of Lockheed Martin.

On page 5 of the spec., it shows that the SysML4Modelica profile references the SysML profile (Figure 2 in the screenshot below):

But I believe that’s an error. I believe that a «reference» dependency is only legal from a profile to a metamodel.

One profile can «import» another profile (and thus transitively reference a metamodel), but not «reference» another profile.

A UML dependency can be between any two NamedElements. The dependency can also be tagged with any stereotype and be given any name. So the <<reference>> dependency is by itself legal. However, a keyword such as <<import>> can also be applied to a dependency.The <<import>> keyword seems more suitable to be applied on a dependency between profiles. So the <<reference>> dependencies to the UML4SysML metamodel (as shown in the SysML spec) in Figure 2 are kept and the <<reference>> dependency between the SysML4Modelica and SysML profiles in Figure 2 is replaced by an <<import>> dependency.

P6 uses ‘meta-case’ for transformation technology.

The capabilities of meta-CASE tools are not well-known. Therefore, the sentence
mentioning the implementation of the SysML-Modelica mapping by meta-CASE
tools is relaxed by referring to “tools” in general instead of “meta-CASE” tools.

6.1: this SysML issue does not belong here as such: if a change is needed it should be specified as a detailed edit to the SysML spec. Otherwise just raise the issue in the normal way.

Section 6.1 will be deleted.

Section 8: presumably these are production rules for Modelica syntax. Does this need to be duplicated in this spec?

No Data Available

Figure 2 uses stereotypes such as <<transformation>> that are not defined

The <<transformation>> stereotype is a self-defined stereotype referring to a
mapping definition.

3.1 should reference version 1.1 of QVT.
3.2: It’s not clear how the MDA Foundation Model ‘constitute provisions of this specification’.

Section 3.1 will reference version 1.1 of QVT and Section 3.2 will not refer to any
non-normative references including the MDA Foundation Model.

The QVT does not use the standard URI for the UML metamodel

No Data Available