This issue corresponds to remarks from Pete Rivett regarding the XMI file of the UML metamodel.

The namespace for UML is wrong xmlns:uml="http://www.eclipse.org/uml2/5.0.0/UML"

Remove xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore"
And all eAnnotations (8)

The package URI should conform to OMG’s standard URI="http://org.omg.ucm/1.0/metamodels/base/commons".
It should be https://www.omg.org/spec/UCM/20190501/ucm_base.uml

Since it’s a metamodel the topmost element should be the Package not the uml:Model

The primitive types do not reference the standard ones:
For example
<type xmi:type="uml:PrimitiveType" href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#String"/>

The URI should be
https://www.omg.org/spec/UCM/20190501/ucm_base.uml

There should be no xmi:type or reference elements such as the above.
There should be no xmi:version.

fix conformity issues in the XMI metamodel file

Fixed the problems the issue points out.

The standard annotations (module ucm_std_ann) defines a set of properties, the type of which is a string (prop_str_t). The base character of this string is “char8”. As these properties are likely to contain text in natural language, it would be better to use wide characters (wchar) instead.

set the character base to wchar in the standard annotations

Issue UCM12-6 is addressed by changing the base character type of string prop_str_t from “char8” to “wchar”.

The shared data connector defined in the standard UCM library involves two port types: sd_writer_pt and sd_reader_pt. In particular, sd_writer_pt is based on an interface that defines three methods: “write_data”, “publish_data” and “cancel_data”. The standard message connector (section 13.1.7) involves a simpler port type msg_emtr_pt, with a single method “push”.
The shared data connector should support port type msg_emtr_pt, as its API (a single method “push”) is simpler. The shared data connector would then offer to alternative port types to publish data: sd_writer_pt and msg_emtr_pt.

enable the use of message send port type in the shared data connector

Add a new connector port sd_simple_writer with port type msg_emtr_pt in the declaration of the shared data connector. Change the XML and IDL declarations accordingly.

The programming model described in section 14.2 shows a set of methods to be implemented by programming language mappings. In particular, the signatures of connection methods are explicitly described (see figure 14.5 on page 77 for on_disconnect and on_connect). These methods are restrictive, as they force some "dynamic" programming: port elements are accessed from their names.
Section 16.7 indicates the corresponding mapping to C++11, with the same method signatures.
However, section 16.9 indicates there could actually be two approaches for a C++ mapping: one based on strongly typed methods, and the other based on generic methods. Section 16.7 describes the later one.

Section 16.9 is so small it might be completely overlooked, while it states a very important point: both generic and strongly typed mappings are necessary. Generic API is nice as it provides flexibility when creating applications, but it prevents addressing real-time critical systems, as it manipulates strings (which cannot guarantee execution time). On the opposite, a strongly typed API completely suits cricital systems as it enables far more predictable execution time, but it also prevent flexibility in the implementation, and is almost always coupled with code generation.

Section 16.9 shows that the UCM standard identified the two mapping approaches, and decided to allow both. But it is not explicit enough. The definition of the programming model in section 14.2 should explicitly address the two possibilities (generic and strongly typed). Section 16 should explicitly explain that UCM actually defines TWO standard mappings for C++11: one with generic API and the other with a strongly typed API.

clarify the UCM programming model and C++ mapping w.r.t. port element connection

Rename the “programming model” into “container model”, as the name was not approriate. Rewrite the container model section to focus on its structure and explain that most parts of the API depend on the programming language mappings.
Be more explicit about the two C++ mapping strategies: generic and strongly typed.

The document contains some typos.

In section 9.2.8 (Abstract type declarations), the end of the first paragraph contains an error: “(§ Error: Reference source not found)”.

In section 10 (XML syntax for UCM declarations), in the sentence that starts with “Basically, every UCM concept described in the meta-model (see section [9]) corresponds…”, the section number (9) is plain text while it should be a link to section 9.

In section 13 (Specification of UCM platform capabilities), a reference to a document is missing in the second paragraph.

In section 13.1.2.1 (From connectors to fragments), there are several typos.

• in the first paragraph, “As states by the UCM metamodel"
• in the second paragraph, “Ex: the fragments of DDS based connector implementation…”

In section 14.1.2.2 (From technical policies to fragments), “As for the connector PortElements…” should be replaced by “Like for the connector PortElements…”.

In section 14.2.1.4 (Connectable), in the first line of the first paragraph, “shallt” should be “shall”.

In section 15.7 (UCM module mapping), the IDL code block is colored, while all code blocks in the document are written in black. Same thing in sections 15.8.2 (Atomic Component Implementation mapping), 15.8.4 (Port mapping), 15.8.5 (Technical Policy Mapping).

In section 15.11 (Component Programming Model), in the second paragraph, “programing” should be spelled “programming”.

In section 16.10.2 (Enumeration mapping), the C++ code block is colored while all code blocks in the document are written in black.

fix the typos found in the document

Fix the typos.

In the UCM specification document, contraint of technical aspect “comp_exec_asp” is “exactly_one”, which means a given atomic component implementation must have one and only one technical policy that specifies its execution. For example, either passive unprotected, passive protected or active protected
However, in the XML file of the core library, technical aspect “comp_exec_asp” is specified with constraint “any_number”. This is inconsistent with the specification document

set the constraint of technical aspect comp_exec_asp to “exactly_one” in file ucm_core.xml

Replace file ucm_core.xml by its new version that fixes the declaration of technical aspect comp_exec_asp.

Although it is not explicitly specified in the standard, UCM modules cannot be
declared in several parts. Hence, a UCM module and all its submodules must be
gathered in a single file; such a file may be difficult to read if there are
many submodules.

It would be nice to introduce the notion of name space in UCM. A UCM name space
would be a specific kind of module that can contain any type of module. A UCM
name space could be declared several times (each declaration in a separate
file).

Example:
In file sys--components.xml

<namespace name="sys">
  <componentModule name="components">
  […]
  </componentModule>
</namespace>

In file sys--contracts.xml

<namespace name="sys">
  <contractModule name="contracts">
  […]
  </contractModule>
</namespace>

Currently, only the following declarations are allowed:

<applicationModule name="sys">
  <componentModule name="components">
  […]
  </componentModule>
  <contractModule name="contracts">
  […]
  </contractModule>
</applicationModule>

This would enable split a large UCM model in several files while keeping a
common naming scheme.

add the notion of namespace

Issue UCM12-1 is addressed by creating a new class named “Namespace” in the metamodel. This class derives from class “IModule”.
The meta-model and the XML representation (DTD and schema) are updated.