When a feature subsets a feature chain, the subsetting feature inherits features from the last feature in the subsetted feature chain. However, the OCL for the operation directionOf in 8.3.3.1.10 Type does not take this into account. It traverses upwards in the specialization and conjugation hierarchy without checking for feature chains.

For example, consider the model

behavior B {
    composite step s { in x; }
}

struct S {
    step b : B;
    feature f {
        feature c chains b.s;
        step s1 subsets c { out x1 redefines x; }
    }
}

In this model, the in parameter x is inheritable from b.s, so it can be redefined by x1 in step s1. However, according to the constraint validateRedefinitionDirectionConformance, one would expect that it would be an error to redefine x1 to be an out parameter, since x is an in parameter. But validateRedefinitionDirectionConformance uses the directionOf operation, which traverses the ownedSpecializations of feature c without considering its feature chaining. As a result, the directionOf parameter x relative to s1 is null rather than in, and the desired constraint does not apply.

The properties Expression::result and Function::result subset parameter, which means they do not have to be ownedFeatures.

The description of deriveExpressionResult states that

If an Expression has a parameter owned via a ReturnParameterMembership, then that is its result parameter. Otherwise, its result parameter is the result parameter inherited from its function.

As written, the OCL interprets this as meaning that the result parameter of an Expression is either owned by that Expression or inherited from the function of that Expression. However, this derivation does not allow for the possibility that an Expression might inherit its result parameter from a supertype Expression. It would seem to make more sense just to select the result as the parameter owned via a ReturnParameterMembership, whether directly owned or inherited (i.e., owned by a supertype) .

Somewhat similarly, the description of the constraint deriveFunctionResult states that

The result parameter of a Function is its parameter owned via a ReturnParameterMembership (if any).

However, the OCL requires that the result parameter of a Function be owned by that Function and cannot be inherited. That seems to be more restrictive than was intended for this constraint.

In 8.3.2.4.5 Namspace, the description of the visibleMembership operation states that "If isRecursive = true, also recursively include all visible Memberships of any visible owned Namespaces." According to the OCL "visible owned Namespace" means any owned Namespace with public visibility.

However, if a recursive import has includeAll = true, then it would seem to be expected that the recursion would continue through all nested namespaces, not just those with public visibility. Indeed, Expose relationships always have includeAll = true, specifically so elements can be exposed in views without regard to visibility. Right now, though, a recursive Expose will not include any elements from private nested Namespaces,

Annotation relationship creation modifies navigable AnnotatingElement::annotation property.

There is a navigable AnnotatingElement::annotation property, so it means AnnotatingElement is modified if Annotation is connected to it. KerML allows Annotation to be defined outside AnnotatingElement, for example AnnotatingElement can be owned in rootNamespace1, but Annotation connecting to that AnnotatingElement can be owned in rootNamespace2.

This causes exactly same problems with models serialization as UML had with NamedElement::clientDependency before making it derived.

If possible AnnotatingElement::annotation should be non-navigable or derived.

The pilot implementation creates a Subsetting from FeatureChainExpression.result to FeatureChainExpression.targetFeature in this example:

package Q {
  part def F {
       part a : A;
  }
  
  part f : F;
  
  part def A {
    part g = f.a;
  }
}

The line part g = f.a parses into:

This is very similar to CheckFeatureResultSpecialization, but there is no CheckFeatureChainExpressionResultSpecialization constraint in the specification defined which would cover this case.

1. In 8.3.3.3.10 Subsetting, in the description of validateSubsettingUniquenessConformance, change the second occurrence of subsettedFeature to subsettingFeature.
2. In 8.3.4.5.3 Connector, in the OCL for checkConnectorBinaryObjectSpecialization, "AssocationStructure" should be "AssociationStructure".
3. In 8.3.4.5.4 Succession, in the OCL for checkSuccessionSpecialization, "Occurences" should be "Occurrences".

Pilot implementation creates implied Subsetting for SelectExpression::result, but there is nothing in the spec for this situation. There is no information in semantic chapter “8.3.4.8.15 SelectExpression”, no formal constraint. Is that a miss in the spec?

Subclause 8.3.3.1.10 (Type), includes inheritedMemberships as an operation with a text description, but no OCL.

The way KerML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.

As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.

Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.

Note: a similar issue will be raised on SysMLv2

KerML association end textual notation/abstract syntax give multiplicity, ordering, and uniqueness that can be redundantly stated on the corresponding features of associated classifiers (association ends in SysML1.x/UML sense, see KERML_-16 about terms), eg, in Occurrences:

Occurrence::suboccurrences [1..*] {...}

HappensDuring {end shorterOccurrence [1..*] subsets longerOccurrence.suboccurrences;}

making it possible for multiplicities, ordering, and uniqueness to get out synch between the features, and potentially be inconsistent. See kerml-assoc-redundancy-issue-description-v2.pdf slides attached.

Current spec mandates that messages are implemented as flow connectors without ends.
>> (8.4.9.6, page 389, "A message declaration of the form ....
>> is parsed as an abstract FlowConnectionUsage, but without any connectionEnds (see 8.2.2.13.4 ),")

Instead, the connectivity information (what this connector is attached to) is implemented as
sourceEvent and targetEvent parameters that need to be redefined.

This is problematic from implementation standpoint as now we need two different codes for drawing/displaying conectors -
one for all connectors except messages and another one for messages.

There seems to be no strong reason why it should be so. Even the very abstract, non-structural,
purely-behavioral connectors, such as Successions do have ends.
It would be better to make message connectors as connectors with ends, as all other connectors.

The only reason to implement them this way seems to be - to make messages "more" distinguishable from flows.
As there is no special metaclass for messages, the same FlowConnectionUsage is reused.
So flow connection with no ends => message, flow connection with ends =>flow seems to be distinguishing criterion.

Now, if user creates connector ends explicitly/forcefully (using the extended syntax of {<connectorbodydetails>}),
the message connection ceases to be distinguishable from flow connection.
But this is a problem, since users do want to specify message connection ends - namely to indicate the sending and receiving parts.

The spec vaguely says (in chapter 7.13.6) that messages should be abstract, while flows (supposedly) should not be so.
The reasoning for no ends for messages seems to be that connectors without bound ends are abstract connectors (there is such a rule elsewhere in the spec),
thus guarranteeing that connector is abstract; but that is a resoning in the opposite direction
(binding of connector ends should not/does not prevent the connector from being abstract).

A better rule to distinguish messages and flows perhaps could be devised.
Heavyweight approach would be to have a dedicated metaclass for messages, but we understand that this would be a signifficant spec change.
Criterion of inheritance from appropriate library class seems to be sufficient?

To summarise:

a) we propose that messages could also have normal connector ends bound to parts.
Perhaps this could be analogous to the arrangement that flow connectors currently have:
when specifying flow connector as being from a.b.c to d.e.f,
the connector ends are filled as a.b and d.e, while the last steps in the chain - c and f go into special flow-specific features.
In the same manner when message is specified as being from a.b.c to d.e.f, the connector ends could be filled as
as a.b and d.e, while the last steps in the chain - c and f (EventOccurrences) go into message-specific features .

b) The rule to distinguish messages and flows should be revised.

8.4.4.9.4 Invocation Expressions states that:

An InvocationExpression may also have the form T(e1, e2, ...), where the invoked Type T is not a Function. In this case, the InvocationExpression acts as a constructor for an instance of the Type T.

The semantics are then that such a constructor expression is both typed by T and a subset of Performances::evaluations. Now, it is allowable for T to be a data type or a structure, that is, for it to directly or indirectly specialize Base::DataValue or Objects::Object). But this is a semantic inconsistency, because Performance (a generalization of evaluations) is disjoint with both DataValue and Object.

Resolution KERML_-82 to issue KERML_-37, approved in FTF2 Ballot 1, resulted in a property targetFeature to the metaclass Feature. Unfortunately, this causes a name conflict with the similar named properties that already exist in Feature subclasses Connector and FeatureChainExpression.

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

The term "Item" in the KerML specification is colloquial and pre-existed the introduction of "Item" as a SysML concept. In SysML "Item" is restricted to an Object (Occurrence), disjoint with DataValue. This means that "Items" in SysML cannot be DataValues (for attributes). This is NOT what is specified in KerML, despite the use of the term "Item" there.

Thus, "ItemFlow" in KerML section 8.3.4.9.3 does not correspond at all to "Items" in SysML.

Because users are looking to KerML for descriptions of the foundational semantics underneath SysML, SysML users and vendors will be looking at KerML to understand semantics around flows at the KerML level to inform how to interpret SysML. Because of this, the use of "Item" as a term in KerML is confusing.

Clauses 7.4.8.1 (Functions Overview) and 8.4.4.8.2 (Expressions and Invariants) say

An invariant, though, is a boolean expression that must always evaluate to either true at all times or false at all times. By default, an invariant is asserted to always evaluate to true, while a negated invariant is asserted to always evaluate to false.

Expressions are kinds of Steps. The checkExpressionSpecialization constraint requires that Expressions specialize the base Expression Performances::evaluations (see 9.2.6.2.3), which is a specialization of Performances::performances.

the checkInvariantSpecialization constraint requires that Invariants specialize either the BooleanExpression Performances::trueEvaluations (see 9.2.6.2.2) or, if the Invariant is negated, the BooleanExpression Performances::falseEvaluations (see 9.2.6.2.2), both of which are specializations of Performances::booleanEvaluations.

where the Performance library defines

abstract expr trueEvaluations subsets booleanEvaluations { true }

abstract expr falseEvaluations subsets booleanEvaluations { false }

but do not require models to specify when invariant expressions are evaluated, which are the only times the results are required to be true/false. The conditions they test for might be present only when the invariants happen to be evaluated (see KERML-58 for more about this).

In 7.4.13 Metadata, the very last example is the declaration

#SecurityRelated #command def Save;

However, def is not a KerML keyword.

In 9.1 Model Libraries Overview, in the first bullet describing the generation of stable model library UUIDs:

1. In the first sub-bullet, it states "name space identifier shall be the NameSpace_URL UUID, as given in [UUID, D.9] (which is 6ba7b812-9dad-11d1-80b4-00c04fd430c8)." The value given for the NameSpace_URL is incorrect. According to the referenced source standard, it should be 6ba7b811-9dad-11d1-80b4-00c04fd430c8 (the last digit of the first block should be 1, not 2).
2. In the second sub-bullet it states "name shall be the URL constructed by prepending https://www.omg.org/KerML/ to the name of the package..." The URL given here should be the standard OMG base URI https://www.omg.org/spec/KerML/ (this was what was actually used to generate the UUIDS in the standard XMI for the library models).

In 8.4.3.1.2 (Core Semantics Mathematical Preliminaries), second bullet list, second bullet (starting "An interpretation"), says

I = (Δ,Σ,⋅^_T) ... is a 2-tuple

The bullets after this describe three elements for I.

[From Brian Larson] In 8.4.3.1.2 (Core Semantics Mathematical Preliminaries), the co-domain of the interpretation function (.^_T) is expressed as

which seems to say all sequences in S begin with the same element of the universe d ₁, is this intended?

Resolution KERML_-79 to issue KERML_-73, approved in Ballot 1, introduces the new validation constraint validateImportTopLevelVisibility with the OCL:

importOwningNamespace.owningNamespace = null implies 
    visibility = VisibilityKind::private

However, the check in the OCL needs to be on importOwningNamespace.owner rather than importOwningNamespace.owningNamespace, because a filtered import is parsed as having a nested package that is actually owned via a NamespaceImport relationship rather than a Membership. In this case, the package will not have an owningNamespace, but it will still not be the root namespace, because it has an owner.

Clause 7.4.5 (Associations), first two paragraphs after the references at the top describes how to declare associations and use of end features, but the

• only example of association end features is later when explaining the more advanced case of association specialization. The text references an earlier very brief description of end features in 7.3.4.2 (Feature Declaration), which points back to 7.4.5 for more information.

• third paragraph (the one starting "An association is also a relationship between the types") describes related types, but does not mention these are same as the end feature types, as specified by the deriveAssociationRelatedType constraint in 8.3.4.4.2 (Association).

Would helpful for 7.4.5 to include a simple example of association end features near the beginning where they are described, and to explain that related types are the same as end feature types.

In general, Feature::type can have more than one value, and there is no restriction on this for end Features. The Association::relatedType property is derived as all the types of all the associationEnds of the Association. However, Association::sourceType is derived to be just the first relatedType. But consider the following Association:

assoc A {
    end feature x : X1, X2;
    end feature y : Y1, Y2;
}

Even though this is a binary Association (it has exactly two ends), it has four relatedTypes: X1, X2, Y1 and Y2. As a binary Association, though, it (implicitly) specializes the library Association BinaryAssociation, with the first end redefining the source and the second end redefining the target. However, with the current derivation, the sourceType of A will be only X1, and the targetTypes will be X2, Y1 and Y2 – even though X2 is a type of the source end.

Clause 8.4.4.6.1 (Connectors, Semantics) says (see KERML-34 for term definitions)

the checkFeatureEndRedefinition constraint requires that the connectorEnds of a Connector redefine the associationEnds of its typing Associations. As a result, a Connector typed by an N-ary Association is essentially required to have the form (with implicit relatiojnships included):

connector a : A subsets Links::links {
end feature e1 redefines A::e1 references f1;
end feature e2 redefines A::e2 references f2;
...
end feature eN redefines A::eN references fN; }

where e1, e2, ..., eN are the names of associationEnds of the Association A, in the order they are defined in A, and the f1, f2, ..., fN are the relatedFeatures of the Connector. Multiplicities declared for connectorEnds have the same special semantics as for associationEnds (see 8.4.4.5).

while 8.3.3.3.8 (Redefinition), under Description (and similar wording in 7.3.4.5 Redefinition) says

Redefinition is a kind of Subsetting that requires the redefinedFeature and the redefiningFeature to have the same values (on each instance of the domain of the redefiningFeature). This means any restrictions on the redefiningFeature, such as type or multiplicity, also apply to the redefinedFeature (on each instance of the domain of the redefiningFeature), and vice versa.

preventing connector ends from giving a smaller lower multiplicity of the corresponding end of their (association) type. For example, people have exactly two parents, but a connector typed by that association might need to specify a [0..2] multiplicity on the parent end to reflect a particular purpose of identifying parents by that connector (such as "lives with").

This restriction is mentioned informally in Clause 8.4.4.6.2 (Binding Connectors):

Since both associationEnds of SelfLink have multiplicity 1..1, both connectorEnds of a BindingConnector do also.

even though some bindings in the libraries have optional connector end multiplicities (see KERML_-13).

The textual and abstract syntaxes (at least) for association end features do not relate to the corresponding ones in the associated classes (association ends in SysML1.x/UML sense, see KERML-34 for term definitions), leaving modelers and tool builders only non-standard ways of maintaining consistency between them. The libraries use a feature subsetting for this, but are not required to. For example, in Occurrences::HappensBefore, the earlier/laterOccurrence association end features subset the corresponding predecessors/successors features of the asssociated occurrence class by chaining through the other end feature:

assoc all HappensBefore specializes HappensLink, Without {
  end feature earlierOccurrence: Occurrence[0..*] ... subsets laterOccurrence.predecessors;
  end feature laterOccurrence: Occurrence[0..*] ... subsets earlierOccurrence.successors; }

abstract class Occurrence specializes Anything { ...
  feature predecessors: Occurrence[0..*] ... {...}
  feature successors: Occurrence[0..*] ... inverse of predecessors {...} }

End features can be multiply subset, and do not identify which subsetting maintains consistency with the corresponding features in the associated classes, preventing tool builders from depending on the subsetting pattern to identify the corresponding features of the associated classifiers, even if the pattern were required.

Clauses 7.4.5 (Associations) and 8.4.4.5.1 (Associations) say

if an association end has a multiplicity specified other than 1..1, then this is interpreted as follows: For each association end, the multiplicity, ordering and uniqueness constraints specified for that end apply to each set of instance of the association that have the same (single) values for each of the other ends. For a binary association, this corresponds to the multiplicity resulting from "navigating" across the association given a value at one end of the association to the other end of the association.

If an associationEnd has a declared multiplicity other than 1..1, then this shall be interpreted as follows: For an Association with N associationEnds, consider the i-th associationEnd ei. The multiplicity, ordering and uniqueness constraints specified for ei apply to each set of instances of the Association that have the same (singleton) values for each of the N-1 associationEnds other than ei.

but this semantics is not math/modeled. In addition, the text above

• does not seem to consider instances of associated classes that do not participate in any links, because only refers to instances of links. In the Product Selection example, the cart in red on the bottom left of the first slide violates the linkedProduct "end" multiplicity 1..*, but the text above would not detect it because it does not participate in any link.
• Applies multiplicity, ordering and uniqueness to links (last sentence), which don't have these characteristics, rather than a feature with the values of ei from all the links.

The specification gives Feature::multiplicity, ordering, and uniqueness very different meanings for what it calls "end" features (see KERML-34 for definition of terms) than other features. This requires modelers and tool builders to create special cases in their minds and implementations to accommodate it. It also prevents

• connector ends from giving smaller lower multiplicity than their association ends (see KERML-55)
• participant features from specifying how many values they have (see KERML-35)
• multiplicities from being uniquely specified (see KERML-36).

Normally feature multiplicity restricts the number of values of a feature, but for association "end" features it restricts the number of values of the corresponding features of associated classifiers (association ends in SysML1.x/UML sense,(see KERML-34 for definition of terms) about terms), see excepts below. For example, in the Product Selection example, the info feature of association Selection has the usual semantics for multiplicity, but the "end" features linkedCart an linkedProduct do not. The same comments apply to end ordering and uniqueness.

Clause 7.4.5 (Associations) says

The semantics of multiplicity is different for end features from that for non-end features (as described in 7.3.4.2). The end features of an association determine the participants in the links that are instances of the association and, as such, effectively have multiplicity of "1" relative to the association. But, if an association end has a multiplicity specified other than 1..1, then this is interpreted as follows: For each association end, the multiplicity, ordering and uniqueness constraints specified for that end apply to each set of instance of the association that have the same (single) values for each of the other ends. For a binary association, this corresponds to the multiplicity resulting from "navigating" across the association given a value at one end of the association to the other end of the association.

Clause 8.4.4.5.1 (Associations) says

As endFeatures, the associationEnds of an Association are given a special semantics compared to other Features. Even if an associationEnd has a declared multiplicity other than 1..1, the associationEnd is required to effectively have multiplicity 1..1 as a participant in the Link. Note that the Feature Link::participant is declared readonly, meaning that the participants in a link cannot change once the link is created.

If an associationEnd has a declared multiplicity other than 1..1, then this shall be interpreted as follows: For an Association with N associationEnds, consider the i-th associationEnd ei. The multiplicity, ordering and uniqueness constraints specified for ei apply to each set of instances of the Association that have the same (singleton) values for each of the N-1 associationEnds other than ei.

Clause 8.3.3.3.3 (Feature) says

isEnd : Boolean
Whether or not the this Feature is an end Feature, requiring a different interpretation of the multiplicity of the Feature. An end Feature is always considered to map each domain instance to a single co-domain instance, whether or not a Multiplicity is given for it. If a Multiplicity is given for an end Feature, rather than giving the co-domain cardinality for the Feature as usual, it specifies a cardinality constraint for navigating across the endFeatures of the featuringType of the end Feature.

That is, if a Type has n endFeatures, then the Multiplicity of any one of those end Features constrains the cardinality of the set of values of that Feature when the values of the other n-1 end Features are held fixed.

The specification says that association "end" features have exactly one value each (see KERML-34 for spec excerpts and definition of terms), but this semantics is not math/modeled.

The specification and models carry over the terms "association end" and "participant" from SysML 1.x, leaving the meaning of "participant" as it was, but changing the meaning of "association end" to be same as "participant", and providing no term equivalent to SysML 1.x "association end" (see below). This shift makes KerML/SysML 2 associations difficult to understand and discuss among current SysMLers (judging from experience during the submission process), and probably those new to SysML as well.

The specification term "association end" refers to what SySML 1.x calls a "participant" property, a property of links (instances of associations) that each identify exactly one of the things being linked by each link. The library element Link has a feature named "participant", with exactly the same meaning as in SysML 1.x, that generalizes "association end" features, such as the source and target features of BinaryLink. The term "association end" in SysML 1.x refers to properties (typically) of associated classes that on each instance of one associated class identify (potentially zero or multiple) instances of the other associated class that are linked by the association. KerML can model these kind of features, but does not give a name for them.

Clauses 7.4.5 (Associations) and 9.2.3.1 (Links Overview) say

Associations are classifiers that classify links between things (see 9.2.3.1) At least two owned features of an association must be end features (see 7.3.4.2), its association ends, which identify the things being linked by (at the "ends" of) each link (exactly one thing per end, which might be the same thing).

The end features of an association determine the participants in the links that are instances of the association and, as such, effectively have multiplicity of "1" relative to the association.

The participant Feature of Link is the most general associationEnd, identifying the things being linked by (at the "ends" of) each Link (exactly one thing per end, which might be the same things).

where Association::associationEnds identify participant features.

The above use of "association end" in the specifiation is reflected in the textual syntax for assocations by the keyword "end" identifying these participant features. Clause 8.4.4.5.1 (Associations) says:

n-aries have this form:

uassoc A specializes Links::Link {
end feature e1 subsets Links::Link::participant;
end feature e2 subsets Links::Link::participant;
...
end feature eN subsets Links::Link::participant; }

The Link instance for an Association is thus a tuple of participants, where each participant is a single value of an associationEnd of the Association.

The quoted text above is only about the equivalent of SysML 1.x participant properties, but might seem to current SysMLers to be about something equivalent to SysML 1.x association ends.

Clauses 8.4.4.6.2 (Binding Connectors) and 7.4.6.3 (Binding Connector Declaration) says they have end multiplicity 1..1 on both ends:

Binding connectors are binary connectors that require their source and target features to have the same values on each instance of their domain. They are typed by the library association SelfLink (which only links things in the modeled universe to themselves, see 9.2.3.1) and have end multiplicities of exactly 1. This requires a SelfLink to exist between each value of the source feature and exactly one value of the target feature, and vice-versa.

The connector ends of a binding connector always have multiplicity 1..1.

but there is no constraint for this on BindingConnector, which might be good because the libraries sometimes have optional mutiplicities, for example:

Occurrences:
  binding unionsOf.union[0..1] = self[1];
Transfers:
  private binding instant[0..1] of startShot[0..1] = endShot[0..1]
Control Performances:
  binding loopBack of untilDecision.elseClause[0..1] = whileDecision[1];

might be others.

SelfLink connectors with one optional end multiplicity are equivalent to feature subsetting (without the inheritance restrictions), rather than the typical meaning of "bind". Perhaps these should have a different textual keyword?

Background

Consider the flowing simple structure:

struct Car {
  feature carEngine : Engine[1];
  feature carWheels : Wheel[4];
  
  connector carDrive : Drive
    from carEngine to carWheels;
}

The feature multiplicities in this model require that each instance of Car have exactly one Engine and exactly four Wheels. The model also includes a usage of the following association:

assoc Drive {
  end feature driveEngine : Engine[0..1];
  end feature driveWheel : Wheel[2..4];
} 

The Drive end multiplicities require that every Engine is connected to 2 to 4 Wheels, while every Wheel is connected to at most 1 Engine. But each instance of the association Drive is a link between a single engine and a single wheel. The multiplicities of the end features of Drive are thus interpreted differently than those of the features of Car (but consistently with how UML and SysML v1 interpret association end multiplicity). Rather than constraining the values of the end features themselves, the end multiplicities constrain the number of links allowed when the value at one end is held fixed: if a value is given for the driveEngine, then there must be two to four Drive links from that driveEngine to different Wheels; if a value is given for the driveWheel, then there must be zero or one instances between that driveWheel and an Engine.

For example, consider the following usage of Car that explicitly binds all the Car features:

feature myCar : Car {
  feature :>> carEngine = myEngine;
  feature :>> carWheels =
    (leftFrontWheel, rightFrontWheel, leftRearWheel, rightRearWheel);
  
  connector :>> carDrive =
    ( Drive(myEngine, leftRearWheel),
      Drive(myEngine, rightRearWheel)
    );
}

The connector ends of the connector carDrive inherit their end multiplicities from the ends of the association Drive. The above model explicitly binds the carDrive connector to two Drive values:

1. a connection from myEngine to leftRearWheel

2. a connection from myEngine to rightRearWheel

This satisfies the multiplicity constraint for Drive, because the carEngine is linked to two Wheels (presuming leftRearWheel and rightRearWheel are different) and each carWheel is connected to at most one Engine.

Concern

While the semantic interpretation of the multiplicity of end features is different than that of non-end features, the same textual notation is used in both cases. This can be confusing, making it seem like, e.g., each instance of Drive has 0 or 1 driveEngine and 2 to 4 driveWheels, which would be the case for regular features but not for end features.

Proposal

Change the textual notation so that the multiplicity of an end feature is placed immediately after the end keyword, rather than in the usual place for a feature declaration. For example:

assoc Drive {
  end [0..1] feature driveEngine : Engine;
  end [2..4] feature driveWheel : Wheel;
}

This would not require a change in the abstract syntax.

Type unioning, intersecting, and differing are described as

Unioning, intersecting, and differencing are relationships between an owning type and a set of other types.
1. Unioning specifies that the owning type classifies everything that is classified by any of the unioned types.
2. Intersecting specifies that the owning type classifies everything that is classified by all of the intersecting types.
3. Differencing specifies that the owning type classifies everything that is classified by the first of the differenced types but not by any of the remaining types.

but this semantics is not math/modeled.

Composite features (Feature::isComposite=true) are described as

Values of a composite feature, on each instance of the feature's domain, cannot exist after the featuring instance ceases to exist. This only applies to values at the time the instance goes out of existence, not to other things in the co-domain that might have been values before that.

but this semantics is not math/modeled and Core does not include models of time.

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

Clause 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature) say

Portion features are composite features where the values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.)

isPortion : Boolean
Whether the values of this Feature are contained in the space and time of instances of the domain of the Feature and represent the same thing as those instances.

and Clause 9.2.4.1 (Occurrences Overview) includes an extended description of time and space modeling in occurrences. But the specification does not explain how to model things (objects and performances) at specific times or places, versus over time or space. For example, cars are driven by one person at a time, but potentially many people over time. How should these multiplicities be specified? See other examples in comments on KERML-204.

Consider the following example:

classifier Organization
classifier Car {
    feature drivers : Person; 
}
classifier Person {
    feature employer : Organization [1] {
        feature salary;
    }
    feature drivenCars : Car {
        redefines feature drivers = that;
    }
}

Now assume we have an M0 universe with organization 'bestCorp', a car 'fastCar', and two persons 'joe' and 'jane', filling the values of corresponding features of persons with the instance(s) of matching type. This will give the following extents:

Organization: { (bestCorp), (joe, bestCorp), (jane, bestCorp) }
Car: { (fastCar), (joe, fastCar), (jane, fastCar) ...? }
Person: { (joe, jane), ...? }
employer: { (joe, bestCorp), (jane, bestCorp) }
salary: { (joe, bestCorp, 100000), (jane, bestCorp, 120000) }
drivenCars: { (joe, fastCar), (jane, fastCar) ...? }
Car::drivers: { (joe, fastCar, joe), (jane, fastCar, jane) ...? }
Person::drivenCars::drivers: { (joe, fastCar, joe), (jane, fastCar, jane), ...? }

Some questions that highlight the meaning of this interpretation:

• Who is Joe's employer (i.e., what is the value of joe.employer)?
  • It is bestCorp.
• Do Jane and Joe work at the same company (i.e., jane.employer == joe.employer)?
  • Yes, the values of these features are the same (bestCorp).
• Do Jane and Joe earn the same at bestCorp (i.e., jane.employer.salary == joe.employer.salary)?
  • No, the values of the feature "salary" for (jane, bestCorp) and (joe, bestCorp) are not the same.
• What car does Joe drive (i.e., what is the value of joe.drivenCars)?
  • He drives fastCar.
• Do Jane and Joe drive the same car (i.e., jane.drivenCars == joe.drivenCars)?
  • Yes, the values of these features are the same (fastCar).
• Who are the drivers of Joe's car (i.e., what is the value of joe.drivenCars.drivers)?
  • They are only Joe because Person::drivenCars::drivers maps from a pair of Joe and fastCar to Joe.
• Who are the drivers of Jane's car (i.e., what is the value of jane.drivenCars.drivers)?
  • They are only Jane because Person::drivenCars::drivers maps from a pair of Jane and fastCar to Jane.
• Who are the drivers of fastCar (i.e., fastCar.drivers)?
  • Nobody, because there is no sequence beginning with fastCar.

The last three questions show the unintended behavior, while those with the employer demonstrate that sometimes this is indeed the desired meaning.

Following the terminology of https://conradbock.org/relation3.html, the underlying problem is that drivenCars is interpreted both as a mapping (or relation) from Person to Car and as a role type specializing Car. Features nested under other features could either be interpreted as the feature of the mapping (or relation), or to the role type. This becomes clear if one tries to refactor this to avoid features nested under features by introducing another classifier:

classifier Organization
classifier Car {
    feature drivers : Person; 
}
classifier Employer :> Organization { 
    feature salary;
}
classifier DrivenCar :> Car {
    // ...?
}
classifier Person {
    feature employer : Employer [1];
    feature drivenCars : DrivenCar;
    bind drivenCars.drivers = self;
}

In this case, the extents would look like this:

Organization: { (bestCorp), (joesEmployer), (janesEmployer) }
Car: { (fastCar), (joesCar), (janesCar) ...? }
Person: { (joe, jane), ...? }
employer: { (joe, joesEmployer), (jane, janesEmployer) }
salary: { (joesEmployer, 100000), (janesEmployer, 120000) }
drivenCars: { (joe, joesCar), (jane, janesCar) ...? }
Car::drivers: { (joesCar, joe), (janesCar, jane) ...? }
DrivenCars::drivers: { (joesCar, joe), (janesCar, jane), ...? }

Answers to the above questions change:

• Who is Joe's employer (i.e., what is the value of joe.employer)?
  • It is joesEmployer.
• Do Jane and Joe work at the same company (i.e., jane.employer == joe.employer)?
  • *No, the values of these features are different (janesCorp vs. joesCorp).
• Do Jane and Joe earn the same at bestCorp (i.e., jane.employer.salary == joe.employer.salary)?
  • No, the values of the feature "salary" for janesCorp and joesCorp are not the same, although we do not know that they work at bestCorp (see previous answer).
• What car does Joe drive (i.e., what is the value of joe.drivenCars)?
  • He drives joesCar.
• Do Jane and Joe drive the same car (i.e., jane.drivenCars == joe.drivenCars)?
  • No, the values of these features are different (janesCar vs. joesCar).
• Who are the drivers of Joe's car (i.e., what is the value of joe.drivenCars.drivers)?
  • They are only Joe because his car is joesCar and that is associated only with Joe.
• Who are the drivers of Jane's car (i.e., what is the value of jane.drivenCars.drivers)?
  • They are only Jane because his car is joesCar and that is associated only with Jane.
• Who are the drivers of fastCar (i.e., fastCar.drivers)?
  • Nobody, because there is no sequence beginning with fastCar.

Documentation for Within, WithinBoth, and SpaceSliceOf in the specification and libraries say they're transitive, but this isn't formalized in the libraries (might be others), as it is for some other time/space associations.

The KerML abstract syntax defines EndFeatureMembership, ParameterMembership, and ReturnParameterMembership.

These concepts do not add additional semantics to the model, as the same can be expressed using FeatureMembership with the appropriate Feature::isEnd and Feature::direction values on owningFeature.

Abstract syntax users (implementors and SysML v2 API users), are confused about which type of membership to use.

Proposal:
Eliminate EndFeatureMembership and ParameterMembership from the abstract syntax.

These modeling aspects are fully covered by Feature::isEnd and Feature::direction.

Portion features (Feature::isPortion=true) are described as

Portion features are composite features where the values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.)

but this semantics is not math/modeled, at least not in Core, which does not include models of time or space. A syntactic constraint that isPortion implies isComposite also seems to be missing.

7.3.4.1 (Features Overview) says

Values of a composite feature, on each instance of the feature's domain, cannot exist after the featuring instance ceases to exist.

and 8.3.3.3.3 (Feature) says

isComposite : Boolean
Whether the Feature is a composite feature of its featuringType. If so, the values of the Feature cannot exist after its featuring instance no longer does.

but the spec doesn't seem to say anywhere that the values cannot be values of any composite features on any other instance of the feature's domain ("single owner", "tree" property of composition), as typically expected.

Currently, the default visibility for an Import relationship is public (see KerML specification, 8.3.2.4.1, Figure 8). This is consistent with the default visibility for Membership relationships. This means that, by default, any memberships that are imported into a namespace are also visible memberships that are "re-exported" out of the importing namespace.

Now, imports are often used just to make names from on namespace available without qualification within another namespace, with no real intention of re-exporting those names. Nevertheless, unless a modeler explicitly changes the import visibility to private from the default of public, then the names will still all be re-exported anyway. Such re-exporting when unnecessary can have a significant, unintentional impact on the performance of name resolution for a large textually represented model by greatly increasing the space of visible names that need to be searched.

If, on the other hand, import relationships were private by default, then they could still be easily used for importing into a namespace. However, the modeler would then need to make an explicit decision to change the visibility to public if it is desired to re-export the imported names, with, presumably, an explicit consideration of the consequences of doing so.

When a Feature has chainingFeatures, then it is sometimes useful to reference that last Feature in the chain in situations in which one would otherwise reference the owning Feature itself if there was no chain. For instance, in a graphical view, an edge with a chained Feature at an end will generally point to the last chainedFeature (possibly nested) rather than the chained Feature itself.

Currently, this means that it is necessary to check for a feature f whether f.chainingFeature is non-empty and, if so, use f.chainingFeature->last() instead of f. It would be more convenient to have a derived property of Feature (called, say, targetFeature) that would do this automatically, that is, be derived as

targetFeature = if chainingFeature.isEmpty() then self else chainingFeature->last() end if

[From Steve Jenkins ] In 9.2.4.2.5 (HappensLink), Description, second sentence says

They cannot happen in time (be Occurrences), making them disjoint with LinkObject.

and in Transfer.kerml, HappenLink documentation, starting in the second sentence, says

... they cannot also be Occurrences that happen in time. Therefore HappensLink is disjoint with LinkObject, that is, no HappensLink can also be a LinkObject.

which give disjointness more narrowly than the justifications just before them. The declaration of HappenLink in Transfer.kerml is

assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...

aligning with the disjointness justifications above.

[From Steve Jenkins and Mr. Hans Peter de Koning] Transfers.kerml says

interaction TransferBefore specializes Transfer, HappensBefore
                           intersects Transfer, HappensBefore { ...

where Transfers are Occurrences and HappensBefores are HappensLinks, if you chase up the taxonomy, but Occurrences.kerml says

assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...

so TransferBefore is only interpretable as an empty set (ie, it's not "instantiable", unsatisfiable).

Clause 9.2.9.1 (Control Performances Overview) says

Successions going out of Steps typed by DecisionPerformance or its specializations must:
• ...
• be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing
Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

Successions coming into Steps typed by MergePerformance or its specializations must:
• ...
• subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

but the Description sections of 9.2.9.2.1 (DecisionPerformance) and 9.2.9.2.7 (MergePerformance) say:

All such Successions must subset the outgoingHBLink feature of the source DecisionPerformance.

All such Successions must subset the incomingHBLink feature of the target MergePerformance.

respectively. The same sentences appear in ControlPerformances.kerml as documentation for DecisionPerformance and MergePerformance, respectively, and with other wording in their documentation for outgoingHBLink and incomingHBLink, respectively:

Specializations subset this by all successions going out of a decision step.

Specializations subset this by all successions coming into a merge step.

These allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The pattern in the overview above introduces a feature of {featuringBehavior}} (the one featuring the control step) unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions.

[Filed for Mr. Raphael Barbau] Clause 9.2.4.1 (Occurrences Overview), under Portions, first paragraph, the last sentence says

They must be classified the same way as the Occurrences they are portionsOf, or more specialized.

For a behavior with mandatory steps (features with lower multiplicity>1 typed by behaviors), this means every portion of its performances, including every snapshot, would need to have values for these steps, even when the steps are not intended to happen during/inside of that portion. Likewise for a structure with mandatory parts, eg, like an engine in a car, all spaceslices would need to have this part. The semantic above is not math/modeled.

It is allowable to have imports at the top-level in a root namespace. If such an import is public, then anything so imported becomes visible in the scope of the global namespace, without qualification. This can potentially introduce name resolution ambiguities that makes global namespace resolution much more difficult.

For example, consider the following three root namespaces (perhaps from separate textual notation files);

package Namespace1 {
    classifier A;
    classifier B;
}

public import Namespace1::*;
package Namespace2 {
   ...
}

public import Namespace1::*;
package Namespace3 {
   ...
}

The classifiers A and B are now globally available not only as Namespace1::A and Namespace1::B from the first root namespace, but also by the unqualified names A and B from both of the other two root namespaces. (And this ambiguity is not invalid according to the global namespace name resolutions rules in 8.2.3.5.4.)

While it can be useful to be able to import names at the top-level into a root namespace, it does not seem necessary to be able to publicly re-export such names into the global namespace. So, disallowing public imports in the root namespace would simplify global name resolution without really removing any particularly useful functionality.

Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.kerml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.

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.

Read only features (Feature::isReadOnly=true) are described as

Values of read only features on each instance of their domain are the same during the entire existence of that instance

but this semantics is not model/mathed and depends on Kernel for instances existing in time.

The functionality of recursive importing is specified in the Namespace::visibleMemberships operation. If the isRecursive parameter of this operation is true, then the operation calls itself recursively on each Namespace that is a visible member (or any member, if isIncludeAll also is true) of the Namespace the operation was called on originally. This includes not only owned namespaces, but also those that are imported.

Further, the visibleMemberships operation is redefined in Type to also include the visible inheritedMemberships of the Type. This nominally includes memberships inherited via implied Specializations as well as explicitly Specializations. This means that a recursive import will also potentially include a large number of names of standard library elements from Types in the recursive import graph, which is likely not what is intended by the modeler.

So, as currently specified, recursive import unavoidably degrades the performance of any name resolution implementation, while including unintended functionality. To improve this, the following restrictions are recommended on the functionality of recursive import:

1. Require recursive imports to be private.
2. Only recurse on owned Namespaces.
3. Do not included Memberships that are inherited via implied Specializations.

In the KerML semantics, 8.4.4.9.4 Invocation Expressions, the semantic equivalent model for an InvocationExpression used as a "constructor" for a type T (i.e., T(...)) is shown as having its result parameter redefined with a FeatureTyping relationship to T. However, there is no semantic constraint in the abstract syntax to enforce this. Note that this typing is important, because it is to be expected that the result of a constructor is of the type being constructed.

The sentence "Classes are required to (directly or indirectly) subclassify Object from the Objects library model, while Features typed by Classes must subset objects" should be changed to "Structures are required to (directly or indirectly) subclassify Object from the Objects library model, while Features typed by Structures must subset objects".

The OCL for the operation Feature::isFeaturedWithin, as updated in the resolution to KERML-82, is still not correct. If a Feature has no featuringTypes, then it is implicitly "featured within" any Type. Therefore, isFeaturedWithin(type) should always return true in this case. Currently, though, the OCL specifies that it only returns true if type = null.

Figure 4. Elements defines the relationship attribute, as well as several subsets depend on the same relationship though the attribute isn't anywhere to be found exept for in the figure 4.

In the Language Description, in 7.4.9.4 Base Expressions, in the fourth bullet for, it states that "A construction expression is an invocation expression in which the invocation target is a classifier that is not a function." However, in the Abstract Syntax, in 8.3.4.8.5 InvocationExpression, the constraint checkInvocationxpressionConstructorBindingConnector considers a constructor expression to be an InvocationExpression that "does not have an ownedTyping that is a Behavior or an ownedSubsetting of a Feature that is typed by a Behavior, then it must own a BindingConnector between itself and its result parameter." Further, in the Semantics, in 8.4.4.9.4 Invocation Expressions, it states

An InvocationExpression may also have the form T(e1, e2, ...), where the invoked Type T is not a Function. If T is a Behavior other than a Function, then the InvocationExpression performs the Behavior, but has a null (empty) result value. If T is a Type that is not a Behavior, then the InvocationExpression acts as a constructor for an instance of the Type T.

Now, invoking a behavior and having it return a null value doesn't really seem very useful. It would actually be more useful if, consistent with the language description, "invoking" a non-function behavior was considered to be a constructor expression, evaluating to a performance of that behavior. This would, in particular, allow out parameters to be referenced from the instantiated performance. For example:

behavior B {in x; out y; out z;}
feature y1 = B(1).y;
feature b = B(2);
feature y2 = b.y;
feature z2 = b.z;

The mapping given in 9.2.17 from the MOF abstract syntax model to the reflective KerML in abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative KerML.kerml file.

In the KerML Specification, 8.2.4.3.1 Features, the production FeatureIdentification references the properties shortName and name. These should instead be declaredShortName and declaredName.

In 8.4.4.11 Feature Values Semantics, the following binding declaration appear in the second textual notation snippet:

member binding f = e.result featured by T;

and the fourth snippet:

member binding f = e.result featured by that.startShot;

These are both syntactically incorrect. The correct syntax is:

member binding b featured by T of f=e.result;

and

member binding b featured by that.startShot of f=e.result;

Since unnamed features cannot be referred to by name, there is no textual syntax to specialize them in a type subtyping the featuring type, even though the abstract syntax can express this relationship.

Specialization is key in execution, where our current approach is to specialize and restrict user-defined types to a model that has a single (family of) interpretations, which is included in the set of original interpretatios (see Annex A). This involves redefining and subsetting the user-defined type's features.

Based on the above, we can conclude that there is currently no way to describe an execution trace in the textual syntax for a model which contains unnamed elements.

The Type metaclass is concrete (like all the metaclasses in the abstract syntax), making it it syntactically valid to create a Type that is not a Classifier or a Feature. However, Clause 8.4.3.1.2 (Core Semantics Mathematical Preliminaries) requires the set of Types in a model to be the union of the set of Classifiers and Features. This means instances of Type in a model that are not Classifiers or Features are syntactically valid, but not given semantics (it's not possible to tell if instances of such types are valid or not).

In Concrete Syntax subclause 8.2.5.8.2 Primary Expressions, the productions for CollectExpression and SelectExpression refer to the production BodyExpressionMember, which is not actually defined in the concrete syntax grammar. These references should instead be to BodyArgumentMember, as also used in FunctionOperationExpression, and defined later in the same clause.

The description of the checkFeatureParameterRedefinition constraint is

If a Feature is a parameter of an owningType that is a Behavior or Step, other than the result parameter (if any), then, for each direct supertype of its owningType that is also a Behavior or Step, it must redefine the parameter at the same position, if any.

However, the OCL for the constraint does not exclude the result parameter as stated in the description.

There is currently no validation rule/check constraint which enforces that when doing redefinitions, if redefined feature has isEnd=true, then redefining feature must also have isEnd=true;
Which opens modelers to errors, e.g. in the SysML spec,
ControlPerformances::DecisionPerformance::outgoingHBLink:: earlierOccurrence is not marked as "end" feature.

In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

If a Feature is a parameter of an owningType that is a Behavior or Step, other than the result parameter (if any), then, for each direct supertype of its owningType that is also a Behavior or Step, it must redefine the parameter at the same position, if any.

However, in the textual BNF in 8.2.5.8.3 Base Expressions, a NamedArgumentList for an InvocationExpression is parsed with parameter redefinitions in the order of the argument list, not the original parameter list. Indeed, according to the description in 7.4.9.4 Base Expressions, named arguments may be "given in any order". But, if they are given in an order different than the original parameter order, this will violate checkFeatureParameterRedefinition. And then adding implied redefinitions to the InvocationExpression parameters, in the original parameter order, would potentially result each of the InvocationExpression parameters incorrectly redefining two different of the original parameters.

In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

If a Feature is a parameter of an owningType that is a Behavior or Step, other than the result parameter (if any), then, for each direct supertype of its owningType that is also a Behavior or Step, it must redefine the parameter at the same position, if any.

However, in the textual BNF in 8.2.5.8.3 Base Expressions, a NamedArgumentList for an InvocationExpression is parsed with parameter redefinitions in the order of the argument list, not the original parameter list. Indeed, according to the description in 7.4.9.4 Base Expressions, named arguments may be "given in any order". But, if they are given in an order different than the original parameter order, this will violate checkFeatureParameterRedefinition. And then adding implied redefinitions to the InvocationExpression parameters, in the original parameter order, would potentially result each of the InvocationExpression parameters incorrectly redefining two different of the original parameters.

Clause 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature) say

Portion features are composite features where the values cannot exist without the whole, because they are the “same thing” as the whole. (For example, the portion of a person's life when they are a child cannot be added or removed from that person's life.)

isPortion : Boolean
Whether the values of this Feature are contained in the space and time of instances of the domain of the Feature and represent the same thing as those instances.

and Clause 9.2.4.1 (Occurrences Overview) includes an extended description of time and space modeling in occurrences. But the specification does not explain how to model things (objects and performances) at specific times or places, versus over time or space. For example, cars are driven by one person at a time, but potentially many people over time. How should these multiplicities be specified? See other examples in comments on KERML-204.

SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

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.

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.

SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

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.

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.

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.

7.3.4.1 (Features Overview) says

Values of a composite feature, on each instance of the feature's domain, cannot exist after the featuring instance ceases to exist.

and 8.3.3.3.3 (Feature) says

isComposite : Boolean
Whether the Feature is a composite feature of its featuringType. If so, the values of the Feature cannot exist after its featuring instance no longer does.

but the spec doesn't seem to say anywhere that the values cannot be values of any composite features on any other instance of the feature's domain ("single owner", "tree" property of composition), as typically expected.

In Clocks.kerml, the TimeOf function defines the timeContinuityConstraint, which states that (endShots of) immediate predecessors of an occurrence (i.e., those connected via a HappensJustBefore) must get the same timestamp (timeInstant in the model) as the start shot of the occurrence:

inv timeContinuityConstraint {
	doc
	/*
	 * If one Occurrence happens immediately before another, then the TimeOf 
	 * the end snapshot of the first Occurrence equals the TimeOf the second
	 * Occurrence.
	 */
	
	o.immediatePredecessors->forAll{in p : Occurrence; 
		TimeOf(p.endShot, clock) == timeInstant
	}
}	

Compare this to the documentation of HappensJustBefore, which states that "HappensJustBefore is HappensBefore asserting that there is no possibility of another occurrences[sic] happening in the time between the earlierOccurrence and laterOccurrence."

Considering that the intent of the libraries is not to constrain the time model and the format of timestamps, I checked this against three widely-used time models.

With continuous (dense) time, the current formulation of the timeContinuityConstraint might make sense, although it fails to capture that an infinite number of snapshots forming a HappensJustBefore chain may actually take non-zero time.

With discrete time, where a timestamp may be treated as a sequence number, for example, an Integer, the invariant may be too restrictive, as HappensJustBefore could apply to two snapshots that have successive sequence numbers, but have no other occurrence in between them. In fact, in a discrete time model, HappensJustBefore with the current definition degrades to HappensWhile because there is no notion of ordering between events with the same timestamp.

In super-dense time, where a clock is usually represented as a pair of a real value (timestamp) and an integer (sequence number to order events with the same timestamp), the invariant is again not very well defined because a pair with the same timestamp and smaller sequence number is generally considered to be (strictly) "less than".

Overall, I think the difference between HappensBefore and HappensJustBefore cannot be captured in the TimeOf function, but should rather be enforced on the succession graph induced by these relations as specified in the documentation of HappensJustBefore (but not formalized, as far as I am aware), independent of the timestamps. This would imply that the invariant should be removed from the library.

Alternatively, if the intent was to say there is no other possible value between the timestamp of the occurrence and that of its immediate predecessors (which degrades to the current definition with continuous time), the constraint could capture this better by asserting that there is no otherTimeInstant such that otherTimeInstant < timeInstant and TimeOf(p.endShot, clock) < otherTimeInstant. This would allow discrete clocks to assign successive timestamps to occurrences in a HappensJustBefore relation, forbid continuous clocks to assign different timestamps (as there is always another real number between any two), and force pairs in super-dense time to assign pairs with the same timestamp and either the same or successive sequence numbers.

In the KerML semantics, 8.4.4.9.4 Invocation Expressions, the semantic equivalent model for an InvocationExpression used as a "constructor" for a type T (i.e., T(...)) is shown as having its result parameter redefined with a FeatureTyping relationship to T. However, there is no semantic constraint in the abstract syntax to enforce this. Note that this typing is important, because it is to be expected that the result of a constructor is of the type being constructed.

Some (abstract and textual) syntax in Core has (informal) semantics requiring time, such as Feature::isComposite, ::isReadOnly, ::isPortion, as well as ::direction and ::isDerived, see 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature), but Core does not include a time model.

The execution algorithm in Annex A should could more cases.

The execution algorithm in Annex A should could more cases.

Some (abstract and textual) syntax in Core has (informal) semantics requiring time, such as Feature::isComposite, ::isReadOnly, ::isPortion, as well as ::direction and ::isDerived, see 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature), but Core does not include a time model.

In Clocks.kerml, the TimeOf function defines the timeContinuityConstraint, which states that (endShots of) immediate predecessors of an occurrence (i.e., those connected via a HappensJustBefore) must get the same timestamp (timeInstant in the model) as the start shot of the occurrence:

inv timeContinuityConstraint {
	doc
	/*
	 * If one Occurrence happens immediately before another, then the TimeOf 
	 * the end snapshot of the first Occurrence equals the TimeOf the second
	 * Occurrence.
	 */
	
	o.immediatePredecessors->forAll{in p : Occurrence; 
		TimeOf(p.endShot, clock) == timeInstant
	}
}	

Compare this to the documentation of HappensJustBefore, which states that "HappensJustBefore is HappensBefore asserting that there is no possibility of another occurrences[sic] happening in the time between the earlierOccurrence and laterOccurrence."

Considering that the intent of the libraries is not to constrain the time model and the format of timestamps, I checked this against three widely-used time models.

With continuous (dense) time, the current formulation of the timeContinuityConstraint might make sense, although it fails to capture that an infinite number of snapshots forming a HappensJustBefore chain may actually take non-zero time.

With discrete time, where a timestamp may be treated as a sequence number, for example, an Integer, the invariant may be too restrictive, as HappensJustBefore could apply to two snapshots that have successive sequence numbers, but have no other occurrence in between them. In fact, in a discrete time model, HappensJustBefore with the current definition degrades to HappensWhile because there is no notion of ordering between events with the same timestamp.

In super-dense time, where a clock is usually represented as a pair of a real value (timestamp) and an integer (sequence number to order events with the same timestamp), the invariant is again not very well defined because a pair with the same timestamp and smaller sequence number is generally considered to be (strictly) "less than".

Overall, I think the difference between HappensBefore and HappensJustBefore cannot be captured in the TimeOf function, but should rather be enforced on the succession graph induced by these relations as specified in the documentation of HappensJustBefore (but not formalized, as far as I am aware), independent of the timestamps. This would imply that the invariant should be removed from the library.

Alternatively, if the intent was to say there is no other possible value between the timestamp of the occurrence and that of its immediate predecessors (which degrades to the current definition with continuous time), the constraint could capture this better by asserting that there is no otherTimeInstant such that otherTimeInstant < timeInstant and TimeOf(p.endShot, clock) < otherTimeInstant. This would allow discrete clocks to assign successive timestamps to occurrences in a HappensJustBefore relation, forbid continuous clocks to assign different timestamps (as there is always another real number between any two), and force pairs in super-dense time to assign pairs with the same timestamp and either the same or successive sequence numbers.

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?

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.

The phrase "read only" is often enough taken to refer to features/properties that write actions (eg, FeatureWritePerformance) should not be applied to (see library errors in KERML-49, modeler misunderstandings in KERML-3 comments and UML constraint errors in UMLR-815), rather than having constant values, as intended.

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.

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?

The phrase "read only" is often enough taken to refer to features/properties that write actions (eg, FeatureWritePerformance) should not be applied to (see library errors in KERML-49, modeler misunderstandings in KERML-3 comments and UML constraint errors in UMLR-815), rather than having constant values, as intended.

Clause 7.4.5 (Associations), first two paragraphs after the references at the top describes how to declare associations and use of end features, but the

• only example of association end features is later when explaining the more advanced case of association specialization. The text references an earlier very brief description of end features in 7.3.4.2 (Feature Declaration), which points back to 7.4.5 for more information.

• third paragraph (the one starting "An association is also a relationship between the types") describes related types, but does not mention these are same as the end feature types, as specified by the deriveAssociationRelatedType constraint in 8.3.4.4.2 (Association).

Would helpful for 7.4.5 to include a simple example of association end features near the beginning where they are described, and to explain that related types are the same as end feature types.

Clause 8.3.3.1.10 (Type), includes inheritedMemberships as an operation with a text description, but no OCL.

Clause 9.2.10.1 (Transition Performances Overview) requires two connectors typed by associations, to constrain transitionLink and transitionLinkSource:

The Succession constrained by a TransitionPerformance is specified by a Connector between the Succession and its transitionStep, a unique Step typed by TransitionPerformance or a specialization of it, of the same Behavior as the Succession. This connector is
• typed by an Association defined to give a value to the transitionLink of TransitionPerformances,
• has connector end multiplicity 0..1 on the Succession end and 1 on the TransitionPerformance Step end.

The transitionStep above is also connected to the Succession's sourceFeature, because conditions on the Succession depend on each Occurrence of its sourceFeature separately, which TransitionPerformances identify as their transitionLinkSource. This connector is
• typed by an Association defined to give a value to the transitionLinkSource of TransitionPerformances.
• with connector end multiplicity 1 on both ends.

but

• succession could subset transitionStep.transitionLink (equivalent to a binding with optional multiplicity on succession end)

• bind succession's sourceFeature and its transitionStep.transitionLinkSource (1 to 1 end multiplicities)

giving the desired result without introducing new associations for each transitionStep. This would also align it with SysML's modeling pattern specified in TransitionUsage::checkTransitionUsageSuccessionBindingConnector and checkTransitionUsageSourceBindingConnector (after the latter is corrected as proposed in SYSML2-397).

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.

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 9.2.10.1 (Transition Performances Overview) requires two connectors typed by associations, to constrain transitionLink and transitionLinkSource:

The Succession constrained by a TransitionPerformance is specified by a Connector between the Succession and its transitionStep, a unique Step typed by TransitionPerformance or a specialization of it, of the same Behavior as the Succession. This connector is
• typed by an Association defined to give a value to the transitionLink of TransitionPerformances,
• has connector end multiplicity 0..1 on the Succession end and 1 on the TransitionPerformance Step end.

The transitionStep above is also connected to the Succession's sourceFeature, because conditions on the Succession depend on each Occurrence of its sourceFeature separately, which TransitionPerformances identify as their transitionLinkSource. This connector is
• typed by an Association defined to give a value to the transitionLinkSource of TransitionPerformances.
• with connector end multiplicity 1 on both ends.

but

• succession could subset transitionStep.transitionLink (equivalent to a binding with optional multiplicity on succession end)

• bind succession's sourceFeature and its transitionStep.transitionLinkSource (1 to 1 end multiplicities)

giving the desired result without introducing new associations for each transitionStep. This would also align it with SysML's modeling pattern specified in TransitionUsage::checkTransitionUsageSuccessionBindingConnector and checkTransitionUsageSourceBindingConnector (after the latter is corrected as proposed in SYSML2-397).

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.