The doc annotations of the datatypes in standard library Collections.kerml in machine readable document ad/23-02-05 are not aligned with the contents of subclause 9.3.3 of the KerML specification.

The documentation content should be made identical. The text in the KerML specification should be leading when drafting a resolution for this issue.

There is currently no constraint that the typing of a subsetting feature conform to the typing of the subsetted feature. For example, the following is currently considered valid:

classifier A;
classifier B;

feature x : A;
feature y : B subsets x;

even if there is no specialization relationship between A and B. Currently, what happens is that y picks up the additions the additional type A due to the subsetting. So the above declaration for y is essentially equivalent to

feature y: B, A subsets x;

Now, unless A and B are declared as disjoint, it is possible that there are instances classified by both A and B, so that this joint typing of y isn't vacuous. Nevertheless, it seems more useful, for static type checking, to presume disjointness and to disallow the above subsetting unless B can be statically determined to specialize A.

This is relevant, in particular, for connectors, in which the related features are determined using reference subsetting. Consider the following:

assoc C {
   end a: A;
   end b: B;
}

feature a1: A;
feature b1: B;

connector c: C from a ::> b1 to b ::> a1;

Because of the above, this is currently allowed. But, as a result, this really seems to make the typing of association ends pretty much useless for connectors.

The specification in subclause 10.2 lists the textual concrete syntax as one format for model interchange.

However, the textual concrete syntax does not include syntax for the elementId : UUID property of any element specified in such a model interchange. In general, this makes it impossible to derive the net semantic difference between model interchanges of a pair of revisions (or versions) of the same package represented in this format. The elementId identifiers are necessary to detect whether a change constitutes: (1) a newly created element, (2) an updated element (including a moved element), or (3) a deleted element. In general, it will only be possible to derive the net lexical difference. This limitation holds in particular for unnamed (i.e. anonymous) elements, as well as for elements with name and/or shortName changes.

It is therefore debatable whether the textual concrete syntax may be designated as a proper model interchange format.

This limitation of use of the textual concrete syntax as an interchange format should be explicitly addressed through one of the following:

1. Add an explanation of the limitation in the specification.
2. Add a facility in the textual concrete syntax to include representation of the elementId for any element. For usability reasons, implementations should provide a capability to show or hide the elementId snippets in the concrete textual notation editor widgets.

The execution algorithm in Annex A should could more cases.

Derived features (Feature::isDerived=true) are described as

Such a feature is typically expected to have a bound feature value expression that completely determines its value at all times.

Whether the values of this Feature can always be computed from the values of other Feature.

but this semantics is not model/mathed.

KerML supports triggers on quantified time, but not quantified space, eg, that an object moves more than a specific distance, or comes within a specific distance of another, etc.

When redefining features, some metaproperties must be respecified even when they're intended to be the same as the redefined ones, while others don't. For example, feature type and multiplicity do not need to be respecified on a redefining feature when they are intended to be the same as the redefined feature, as I understand it, while direction does, even when it is intended to be the same as the redefined feature. Modelers must remember which feature metaproperties need to be respecified and which don't. The textual syntax would be easier to use if this were the same for all feature metaproperties, and more so if metaproperties could always be omitted in redefining features when they are intended to be the same as the redefined feature.

Literal Values

inout

Values of the Feature on each instance are determined either as in or out directions, or both.

In and out discuss 2 concepts of 'determination' of an instances value, and 'use' of an instances value
Is 'inout' ambiguous as to the features determination and use completely or still constrained?
Both 'in' and 'out' require opposite 'determination' than 'use', but can inout allow same 'determination' and 'use'?
To be more clear, can an inout feature be 'determined' 'externally' and 'used' 'externally'?
How is 'inout' different from not providing a directionality constraint?
How does directionality work with specializations like subsetting/redefinition, should there be constraints?

Usecase: large corporation is working on a project, where also other suppliers deliver parts of the product architecture.

To avoid naming collisions in such constellations, it makes sense to use hierarchical package structures. If everyone just uses plain structures, we have potential conflicts with a duplicate declaration of namespaces.
As within large corporations hundreds of engineers can be working of one product class, which might be organized as namespaces, it makes sense to split the definition of multiple namespaces within the same parent namespace in different files to avoid merge conflicts

Example

package Vehicle{
   part engine : MyCorp::Automotive::Engine::SmallEngine;
   part gearFront : MyCorp::Automotive::Transmission::AT8Gear;
   part rearGear : SomeSupplier::Transmission::FancyGear;
}

Possible resolutions:
1) allow duplicate definitions of namespaces and implicitly merges the resulting trees, dangerous as it could happen unintended
2) allow to merge sub-trees of duplicate namespaces with a keyword
2a) all except one namespace declaration require an addendum keyword, injection of elements possible which might expose private information
2b) all namespaces must declare, that extension is possible

example

partial package CommonParent //declaration can be skipped, if nothing except namespace is declared
package CommonParent::GroupA{
  //some declarations
}
package CommonParent::GroupB{
  //some more declarations
}
package CommonParent::IntegrationLayer{} //should work as no explicitly declared namespace is duplicated
package CommonParent::GroupA::Backdoor {} //should generate an error as the explicitly declared namespace GroupA is duplicated

Clause 8.4.4.12.1 (Multiplicities, Semantics) says

The validateTypeOwnedMultiplicity constraint requires that a Type have at most one ownedMember that is a Multiplicity. If a Type has such an owned Multiplicity, then it is the typeWithMultiplicity of that Multiplicity. The value of the Multiplicity is then the cardinality of its typeWithMultiplicity and, therefore, the type (co-domain) of the Multiplicity restricts that cardinality.

If a Type does not have an owned Multiplicity, but has ownedSpecializations, then its cardinality is constrained by the Multiplicities for all of the general Types of those ownedSpecializations (i.e., its direct supertypes). In practice, this means that the effective Multiplicity of the Type is the most restrictive Multiplicity of its direct supertypes.

The above implies inherited multiplicities do not constrain cardinality of types that

• own a Multiplicity
• inherit them via unowned specializations

while the (math) semantics for specialization and multiplicity says they do (rule 1 in 8.4.3.2, Types Semantics, and rule 5 in 8.4.3.4, Features Semantics, respectively).

The documentation for the validateAssociationStructureIntersection constraint is "If an Association is also a kind of Structure, then it must be an AssociationStructure." with the OCL

oclIsKindOf(Structure) = oclIsKindOf(AssociationStructure)

However, this is really a constraint on the abstract syntax, not user models. Since the current abstract syntax does not have any metaclass that is a subclass of both Structure and Association other than AssociationStructure, this constraint will always be true for every user model. (And, if the abstract syntax did include another subclass of both Structure and Association, then constraint would then be violated by every user model that used that construct!)