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

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.

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.

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

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.

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.

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

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

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

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

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

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.

In 7.4.9.2 OperatorExpressions, in the bullet for "Classification expressions", it states:

The classification operators may also be used without a first operand, in which case the first operand is implicitly Anything::self (see 9.2.2.2.1). This is useful, in particular, when used as a test within an element filter condition expression (see 7.4.14).

In the concrete syntax, in 8.2.5.8.1 Operator Expressions, the production for ClassificationExpression does, indeed, allow the first operand to be optional. However, there is nothing stated there (or anywhere else in normative Clause 8) about the default for the first operand being Anything::self if it is not given explicitly, as stated in 7.4.9.2.

In 7.4.9.2 OperatorExpressions, in the bullet for "Classification expressions", it states:

The classification operators may also be used without a first operand, in which case the first operand is implicitly Anything::self (see 9.2.2.2.1). This is useful, in particular, when used as a test within an element filter condition expression (see 7.4.14).

In the concrete syntax, in 8.2.5.8.1 Operator Expressions, the production for ClassificationExpression does, indeed, allow the first operand to be optional. However, there is nothing stated there (or anywhere else in normative Clause 8) about the default for the first operand being Anything::self if it is not given explicitly, as stated in 7.4.9.2.

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.

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

[From Vince Molnar] Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

Clocks::universalClock[1] {...}
Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
SpatialFrames::defaultFrame : SpatialFrame[1] {...}

Might be others. This one

Occurrences::earlierFirstIncomingTransferSort: IncomingTransferSort{... }

does not give a multiplicity, I couldn't find what this means (even for expressions), tho this particular feature is supposed to have exactly one value.

Clause 8.3.4.10.2 (FeatureValue) and 8.4.4.11 (Feature Values Semantics) say

A FeatureValue is a Membership that identifies a particular member Expression that provides the value of the Feature that owns the FeatureValue.

A FeatureValue is a kind of OwningMembership between a Feature and an Expression.

but does not require the model to specify when the expression is evaluated. Expressions (as steps) owned by some features are required to happen (be evaluated) during instances of the featuring types (domain) of that feature (see KERML-11), which might be too loose for some applications, while those owned other features are unconstrained, for example, their values could be the results of an expression evaluated before or after the instance of domain types exists. The results could vary over time if the expression reads values of other features. This seems to apply to all the combinations of default/initial feature values.

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

Clause 8.3.4.10.2 (FeatureValue) and 8.4.4.11 (Feature Values Semantics) say

A FeatureValue is a Membership that identifies a particular member Expression that provides the value of the Feature that owns the FeatureValue.

A FeatureValue is a kind of OwningMembership between a Feature and an Expression.

but does not require the model to specify when the expression is evaluated. Expressions (as steps) owned by some features are required to happen (be evaluated) during instances of the featuring types (domain) of that feature (see KERML-11), which might be too loose for some applications, while those owned other features are unconstrained, for example, their values could be the results of an expression evaluated before or after the instance of domain types exists. The results could vary over time if the expression reads values of other features. This seems to apply to all the combinations of default/initial feature values.

[From Vince Molnar] Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

Clocks::universalClock[1] {...}
Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
SpatialFrames::defaultFrame : SpatialFrame[1] {...}

Might be others. This one

Occurrences::earlierFirstIncomingTransferSort: IncomingTransferSort{... }

does not give a multiplicity, I couldn't find what this means (even for expressions), tho this particular feature is supposed to have exactly one value.

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

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.

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

Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

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

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.

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

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

Some library types might be intended to be sufficient. For example, in Occurrences::Occurrence, the values of

feature spaceTimeCoincidentOccurrences: Occurrence[1..*] subsets timeCoincidentOccurrences, spaceEnclosedOccurrences ... { ...
  feature redefines thatOccurrence subsets largerSpace;
  feature redefines thisOccurrence subsets smallerSpace;
  connector :InsideOf from largerSpace references thatOccurrence [1]
                      to smallerSpace references thisOccurrence [1]; }

presumably should include all timeCoincident/spaceEnclosedOccurrences that meet the condition given by the connector, but the feature is not marked as sufficient. Might be others like this.

Some library types are sufficient, but do give give any conditions. For example, in Occurrences::Occurrence::

portion feature all portions: Occurrence[1..*] subsets spaceTimeEnclosedOccurrences { ... }

only has text documentation between the curly braces, leaving sufficiency to mean that portions and spaceTimeEnclosedOccurrences are equivalent. Might be others like this.

Performances::Performance and Objects::Object redefine self in the libraries, but Clauses 9.2.6.2.13 (Performance) and 9.2.5.2.7 (Object) are missing entries for these. Might be other self redefinitions missing also.

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.

Some library types might be intended to be sufficient. For example, in Occurrences::Occurrence, the values of

feature spaceTimeCoincidentOccurrences: Occurrence[1..*] subsets timeCoincidentOccurrences, spaceEnclosedOccurrences ... { ...
  feature redefines thatOccurrence subsets largerSpace;
  feature redefines thisOccurrence subsets smallerSpace;
  connector :InsideOf from largerSpace references thatOccurrence [1]
                      to smallerSpace references thisOccurrence [1]; }

presumably should include all timeCoincident/spaceEnclosedOccurrences that meet the condition given by the connector, but the feature is not marked as sufficient. Might be others like this.

Some library types are sufficient, but do give give any conditions. For example, in Occurrences::Occurrence::

portion feature all portions: Occurrence[1..*] subsets spaceTimeEnclosedOccurrences { ... }

only has text documentation between the curly braces, leaving sufficiency to mean that portions and spaceTimeEnclosedOccurrences are equivalent. Might be others like this.

Performances::Performance and Objects::Object redefine self in the libraries, but Clauses 9.2.6.2.13 (Performance) and 9.2.5.2.7 (Object) are missing entries for these. Might be other self redefinitions missing also.

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.

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

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

Clause 8.4.4.6.2 (Binding Connectors) says

binding f1 = f2;

is equivalent to

connector subsets Links::selfLinks {
  end feature thisThing redefines Links::SelfLink::thisThing references f1;
  end feature thatThing redefines Links::SelfLink::thatThing references f2; 

while the next clause, 8.4.4.6.3 (Successions) says

succession first f1 then f2;

is equivalent to

connector subsets Occurrences::happensBeforeLinks {
  end feature earlierOccurrence references f1
    redefines Occurrences::HappensBefore::earlierOccurrence;
  end feature laterOccurrence references f2
    redefines Occurrences::HappensBefore::laterOccurrence; }

The similarity between the clauses implies the first/then notation is short for successions with multiplicity 1..1 on both ends, but the text does not say it, if that's the intention, and should be clarified in any case.

Clause 8.4.4.6.2 (Binding Connectors) says

binding f1 = f2;

is equivalent to

connector subsets Links::selfLinks {
  end feature thisThing redefines Links::SelfLink::thisThing references f1;
  end feature thatThing redefines Links::SelfLink::thatThing references f2; 

while the next clause, 8.4.4.6.3 (Successions) says

succession first f1 then f2;

is equivalent to

connector subsets Occurrences::happensBeforeLinks {
  end feature earlierOccurrence references f1
    redefines Occurrences::HappensBefore::earlierOccurrence;
  end feature laterOccurrence references f2
    redefines Occurrences::HappensBefore::laterOccurrence; }

The similarity between the clauses implies the first/then notation is short for successions with multiplicity 1..1 on both ends, but the text does not say it, if that's the intention, and should be clarified in any case.

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.

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.

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?

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?

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.

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. 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 unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions.

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. 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 unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions.

Sufficient types are (Type::isSufficient=true) are described as

A type gives conditions for what things must be in or not in its extent (sufficient and necessary conditions, respectively).

... the type places additional sufficiency conditions on its instances corresponding to all the necessary conditions.

but this semantics is not math/modeled and the syntax cannot specify that only some necessary conditions are to correspond to sufficient ones.

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.

Sufficient types are (Type::isSufficient=true) are described as

A type gives conditions for what things must be in or not in its extent (sufficient and necessary conditions, respectively).

... the type places additional sufficiency conditions on its instances corresponding to all the necessary conditions.

but this semantics is not math/modeled and the syntax cannot specify that only some necessary conditions are to correspond to sufficient ones.

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.

Clause 8.4.4.7.2 (Steps, under Behavior Semantics) says

The checkStepSpecialization constraint requires that Steps specialize Performances::performances.

checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints require that a Step whose owningType is a Behavior or another Step specialize Performances::Performance::enclosedPerformance or, if it is composite, Performances::Performance::subperformance.

checkStepOwnedPerformanceSpecialization constraint requires that a composite Step whose owningType is a Structure or a Feature typed by a Structure specialize Objects::Object::ownedPerformance.

where enclosedPerformances, subperformances, and ownedPerformances (in)directly subset timeEnclosedOccurrences, the values of which happen during the occurrences "having" the value.

The first constraint leaves open the possibility that steps might not happen during the occurrences they are steps of, bc Performances::performances is a step and subsets occurrences, rather than timeEnclosedOccurrences. This conflicts with the normal meaning of the term "step" (a terminology issue), which typically connotes (in library terms) performances that happen during the occurrences they are steps of.

The second constraint prevents the possibility above for steps owned by behaviors or other steps, while the third only prevents it for composite steps owned by structures.

The step keyword looks like it's sometimes used with other intentions than the constraints indicate. For example, in Observation.kerml:

behavior ObserveChange { ...
  step transfer : TransferBefore[1] ... {
    /* Then send changeSignal to changeObserver. */ ... } ... }

↑ Is it intended that observechange occurrences timeenclose the entire transfer (all the way to it's arrival at its target), as required by the second constraint?

struct ChangeMonitor { ...
  step startObservation { ... }
  step cancelObservation { ... }

↑ Is it intended that the values of start/CancelObservation can happen at other times than the ChangeMonitor occurrence referencing them, as allowed by the third constraint?

Transfers::
  step transfers: Transfer[0..*] nonunique subsets performances, binaryLinks { ... }
  step messageTransfers: MessageTransfer[0..*] nonunique subsets transfers { ... }
  step flowTransfers: FlowTransfer[0..*] nonunique subsets transfers { ... }
  step transfersBefore: TransferBefore[0..*] nonunique subsets transfers, happensBeforeLinks { ... }
  step flowTransfersBefore: FlowTransferBefore[0..*] nonunique subsets flowTransfers, transfersBefore { ... }

↑ These are features of (effectively) Anything, including structures and behaviors, so sometimes they'll be time enclosed and sometimes not. For example:

Occurrence::
  feature incomingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }
  feature outgoingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }

↑ will be time enclosed for transfers into/out of performances, but not objects, assuming the above are redefined as steps in behaviors or structures (or that features specialized from steps are also steps).

Clause 8.4.4.7.2 (Steps, under Behavior Semantics) says

The checkStepSpecialization constraint requires that Steps specialize Performances::performances.

checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints require that a Step whose owningType is a Behavior or another Step specialize Performances::Performance::enclosedPerformance or, if it is composite, Performances::Performance::subperformance.

checkStepOwnedPerformanceSpecialization constraint requires that a composite Step whose owningType is a Structure or a Feature typed by a Structure specialize Objects::Object::ownedPerformance.

where enclosedPerformances, subperformances, and ownedPerformances (in)directly subset timeEnclosedOccurrences, the values of which happen during the occurrences "having" the value.

The first constraint leaves open the possibility that steps might not happen during the occurrences they are steps of, bc Performances::performances is a step and subsets occurrences, rather than timeEnclosedOccurrences. This conflicts with the normal meaning of the term "step" (a terminology issue), which typically connotes (in library terms) performances that happen during the occurrences they are steps of.

The second constraint prevents the possibility above for steps owned by behaviors or other steps, while the third only prevents it for composite steps owned by structures.

The step keyword looks like it's sometimes used with other intentions than the constraints indicate. For example, in Observation.kerml:

behavior ObserveChange { ...
  step transfer : TransferBefore[1] ... {
    /* Then send changeSignal to changeObserver. */ ... } ... }

↑ Is it intended that observechange occurrences timeenclose the entire transfer (all the way to it's arrival at its target), as required by the second constraint?

struct ChangeMonitor { ...
  step startObservation { ... }
  step cancelObservation { ... }

↑ Is it intended that the values of start/CancelObservation can happen at other times than the ChangeMonitor occurrence referencing them, as allowed by the third constraint?

Transfers::
  step transfers: Transfer[0..*] nonunique subsets performances, binaryLinks { ... }
  step messageTransfers: MessageTransfer[0..*] nonunique subsets transfers { ... }
  step flowTransfers: FlowTransfer[0..*] nonunique subsets transfers { ... }
  step transfersBefore: TransferBefore[0..*] nonunique subsets transfers, happensBeforeLinks { ... }
  step flowTransfersBefore: FlowTransferBefore[0..*] nonunique subsets flowTransfers, transfersBefore { ... }

↑ These are features of (effectively) Anything, including structures and behaviors, so sometimes they'll be time enclosed and sometimes not. For example:

Occurrence::
  feature incomingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }
  feature outgoingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }

↑ will be time enclosed for transfers into/out of performances, but not objects, assuming the above are redefined as steps in behaviors or structures (or that features specialized from steps are also steps).

Feature direction (Feature::direction:FeatureDirectionKind) is described as

in, out, inout: Specifies the direction of a feature, which determines what is allowed to change its values on instances of its domain:
-in: Things "outside" the instance. These features identify things input to an instance.
-out: The instance itself or things "inside" it. These features identify things output by an instance.
-inout: Both things "outside" and "inside" the instance. These features identify things that are both input to and output by an instance.

but this semantics is not math/modeled and depends on Kernel for instances changing over time.

Feature direction (Feature::direction:FeatureDirectionKind) is described as

in, out, inout: Specifies the direction of a feature, which determines what is allowed to change its values on instances of its domain:
-in: Things "outside" the instance. These features identify things input to an instance.
-out: The instance itself or things "inside" it. These features identify things output by an instance.
-inout: Both things "outside" and "inside" the instance. These features identify things that are both input to and output by an instance.

but this semantics is not math/modeled and depends on Kernel for instances changing over time.

Abstract types (Type::isAbstract=true) are described as

instances of this Type must also be instances of at least one of its specialized Types.

but this semantics is not math/modeled.

Abstract types (Type::isAbstract=true) are described as

instances of this Type must also be instances of at least one of its specialized Types.

but this semantics is not math/modeled.

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.

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.

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.

Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type (see description of KERML-1). The math semantics for feature multiplicity (rule 5 in 8.4.3.4, Features Semantics) refers to the multiplicity metaproperty on a feature f as model element, rather than the multiplicity feature on an instance of f 's featuring type, preventing it from covering multiplicity values that change over the life of an instance, and possibly not handling constant values either.

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.

Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type (see description of KERML-1). The math semantics for feature multiplicity (rule 5 in 8.4.3.4, Features Semantics) refers to the multiplicity metaproperty on a feature f as model element, rather than the multiplicity feature on an instance of f 's featuring type, preventing it from covering multiplicity values that change over the life of an instance, and possibly not handling constant values either.

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.

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.

Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type. For a feature f, the values of its multiplicity (as a feature) are allowed cardinalities for the collection of values on each instance of f 's featuring type, while for classifiers they are allowed cardinalities for the collection of its instances. Math semantics for feature multiplicity is available (rule 5 in 8.4.3.4, Features Semantics), but missing for classifier multiplicity. Is it intended that every instance of a classifier give the number of allowable instances of that classifier? What if there are no instances?

Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type. For a feature f, the values of its multiplicity (as a feature) are allowed cardinalities for the collection of values on each instance of f 's featuring type, while for classifiers they are allowed cardinalities for the collection of its instances. Math semantics for feature multiplicity is available (rule 5 in 8.4.3.4, Features Semantics), but missing for classifier multiplicity. Is it intended that every instance of a classifier give the number of allowable instances of that classifier? What if there are no instances?

The constraints validatePackageFilterIsBoolean and validatePackageFilterIsModelLevelEvaluable are owned by ElementFilterMembership and apply to its condition property. Therefore, they should be named validateElementFilterMembershipConditionIsBoolean and validateElementFilterMembershipConditionIsModelLevelEvaluable.

The current documentation for validateItemFlowItemFeature is

An ItemFlow must have at most one ownedFeature that is an ItemFlow.

It should be “…that is an ItemFeature.”

The constraint validateDatatypeSpecialization should be named validateDataTypeSpecialization, because the metaclass is named DataType, not Datatype.

The list of symbols shown in Clause 8.2.2.7 lacks several symbols. The symbols missing are ".", ".?", "===" and "!==".

The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.

8.3.17.2 ExhibitStateUsage

1. validateExhibitStateUsageReference – If an ExhibitStateUsage has an ownedReferenceSubsetting, then its referencedFeature must be a StateActionUsage.

8.3.19.2 AssertConstraintUsage

2. validateAssertConstraintUsageReference – If an AssertConstraintUsage has an ownedReferenceSubsetting, then its referencedFeature must be a ConstraintUsage.

8.3.20.10 SatisfyRequirementUsage

4. validateSatisfyRequirementUsageReference – If a SatisfyRequirementUsage has an ownedReferenceSubsetting, then its referencedFeature must be a RequirementUsage.

8.3.24.2 IncludeUseCaseUsage

5. validateIncludeUseCaseUsageReference – If an IncludeUseCaseUsage has an ownedReferenceSubsetting, then its referencedFeature must be a UseCaseUsage.

In 8.3.4.5.3 Connector, in the description of targetFeature, the "p>" at the beginning of the paragraph should be deleted.

The documentation for the checkFeatureEndRedefinition constraint is

If a Feature has isEnd = true and an owningType that is not empty, then, for each direct supertype of its owningType, it must redefine the endFeature at the same position, if any.

However, the OCL for the constraint requires the redefinitions to be of owned endFeatures of the supertypes, which is inconsistent with the constraint documentation, and is also inconsistent with the discussion in Language Description subclauses for Associations and Connectors (7.4.5 and 7.4.6) and with the corresponding Semantics subclauses (8.4.4.5 and 8.4.4.6).

The documentation for validateRedefinitionFeaturingTypes should state that it applies to Redefinition, not Subsetting. The documentation and OCL constraint should also use redefinedFeature and redefiningFeature, rather than subsettedFeature and subsettingFeature.

In clause 7.4.1 Kernel Overview, there is the following sentence:
"For example, classes must directly or indirectly subclassify the library class Object"

I assume the superclass mentioned should be Occurence, not Object.

The following constraints of Feature have no descriptions in the abstract syntax:

• deriveFeatureFeaturingType
• validateFeatureChainingFeatureNotOne

Clause 8.2.5.7.1
The closing apostrophe at the end of line is missing:

FunctionBody : Type =
';' | '{' FunctionBodyPart '}

Also, in the list of reserved words, "assign" is reserved, but doesn't appear in any KerML grammar. (It is a SysML v2 keyword, though).

In the OCL for the Feature constraints validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf in the abstract syntax, the references to chainingFeatures (plural) should be chainingFeature (singular).

In 7.4.7.2 Behavior Declaration, in the sixth paragraph (before the "behavior Focus" example), in the last sentence, "superclassifer" should be "superclassifier".

In subclause 8.4.4.11 Feature Values Semantics, it states that

The checkFeatureValuationSpecialization constraint requires that, if the featureWithValue has no explicit ownedSpecializations and is not directed, then it subsets the result parameter of the value Expression.

However, the specification of checkFeatureValuationSpecialization in subclause 8.3.3.3.3 only requires

If a Feature has a FeatureValue, then it must specialize the result of the value Expression of the FeatureValue.

without the limitation that "the featureWithValue has no explicit ownedSpecializations and is not directed" (and the OCL is consistent with the textual description of the constraint).

The checkFeatureEndSpecialization semantic constraint requires that

If a Feature has isEnd = true and an owningType that is an Association, then it must directly or indirectly specialize Links::Link::participants from the Kernel Semantic Library.

If a Connector is explicitly typed by one or more Associations, then it’s ends will redefine the corresponding Association ends and will thus also indirectly specialize Link::participants. However, if the Connector adds additional ends, then these will not redefine any Association ends and there is currently no requirement that these ends specialize Link::participants. In particular, the base Association Link has no ends, so when an n-ary Connector is implicitly typed by it, none of its ends will redefine Association ends, and so none of them will subset participants, which is semantically incorrect.

The checkFeatureEndSpecialization constraint needs to be updated to also cover such cases.

There are errors in the OCL for the following specialization constraints:

8.3.3.3.3 Feature

checkFeatureDataValueSpecialization and checkFeatureObjectSpecialization – specializesFromLibary should be specializesFromLibrary

8.3.4.6.3 Step

checkStepSpecialization – Should use specializesFromLibrary

In 8.3.4.8.4 FeatureReferenceExpression, the description of deriveFeatureReferenceExpressionReferent is

The targetFeature of a FeatureChainExpression is the memberElement of its first ownedMembership that is not a ParameterMembership.

This description should, instead, start "The referent of a FeatureReferenceExpression is the..."

The Kernel Semantic Library model Performances includes features corresponding to each of the various kinds of LiteralExpression (e.g., literalBooleanEvaluations for LiteralBoolan, literalStringEvaluations for LiteralString, etc.; see KerML specification, 9.2.6.2). However, semantic constraints requiring the LiteralExpressions subclasses to specialize these features are missing in the abstract syntax (see KerML, 8.3.4.8). Adding these constraints would also allow the checkFeatureResultSpecialization constraint (see KerML, 8.3.3.3.3) to be simplified by removing the requirement that “If a Feature has an owningType that is a LiteralExpression it must directly or indirectly specialize the DataType from the ScalarValues package in the Kernel Data Types Library corresponding to the kind of LiteralExpression.” (since this would be automatically satisfied by the implied specializations for each kind of LiteralExpression and the {{checkFeatureResultSpecialization} constraint).

In the constraints validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf, the name chainingFeatures should be chainingFeature. Also, validateFeatureChainingFeatureNotOne needs documentation.

The Behavior ControlPerformances::IfThenElsePerformance specializes IfThenPerformance and IfElsePerformance. However, it does not declare any owned parameters (see 9.2.9.2.4). This violates the rule state in 7.4.7.2 Behavior Declaration that "If there is more than one superclassifier behavior, then every parameter from every superclassifier must be redefined by an owned parameter of the subclassifier." Following this rule would require IfThenElsePerformance to be declared with owned parameters, such as

	behavior IfThenElsePerformance specializes IfThenPerformance, IfElsePerformance {		 
		in ifTest;
		in thenClause;
		in elseClause;
	}

However, as also described in 7.4.7.2, "...each of the owned parameters of the subclassifier behavior must, in order, redefine the parameter at the same position of each of the superclassifier behaviors". This means that IfThenElsePerformance::ifTest has to redefine ifTest from both IfThenPerformance and IfElsePerformance, which is fine. But it also means that IfThenElsePerformance::thenClause has to redefine IfThenPerformance::thenClause and IfElsePerformance::elseClause, which is not what is intended. There is no way to follow this rule and have the third parameter of IfThenElsePerformance redefine the second parameter of IfElsePerformance.

In the Links model library, BinaryLink::source/target are defined as

assoc all BinaryLink specializes Link {
 feature participant: Anything[2] nonunique ordered redefines Link::participant;
 readonly end feature source: Anything[0..*] subsets participant;
 readonly end feature target: Anything[0..*] subsets participant; }

making source/target unique by default (subsets don't inherit ordering/uniqueness). This prevents modelers from defining the corresponding features of associated classifiers as nonunique (see KERML-37), because nonunique is less restrictive than unique.

In the Kernel Function Library model BaseFunctions, in the declaration of the ',' function, the seq2 feature is supposed to be the second input parameter, but it is missing an in direction keyword.

The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.

8.3.3.1.10 Type

validateTypeOwnedUnioningNotOne – A Type must not have exactly one ownedUnioning.

validateTypeOwnedIntersectingNotOne – A Type must not have exactly one ownedIntersecting.

validateTypeOwnedDifferencingNotOne – A Type must not have exactly one ownedDifferencing.

8.3.3.3.3 Feature

validateFeatureChainingFeatureConformance – Each chainingFeature (other than the last) must conform to all the featuringTypes of the next Feature in the chain.

8.3.3.3.8 Redefinition

validateRedefinitionDirectionConformance – If the redefinedFeature of a Redefinition has a non-null direction, then the redefiningFeature must have the same direction.

8.3.3.3.10 Subsetting

validateSubsettingMultiplicityConformance – If the subsettingFeature of a Subsetting has a multiplicity that is a MultiplicityRange, then this must be consistent with the MultiplicityRange (if any) of the subsettedFeature (if the multiplicity bounds are model-level evaluable).

validateSubsettingUniquenessConformance – The subsettingFeature of a Subsetting must not have isUnique = false if the subsettedFeature has isUnique = true.

8.3.4.5.2 BindingConnector

validateBindingConnectorTypeConformance – Either the first end of a BindingConnector should conform to the second, or vice versa.

8.3.4.5.3 Connector

validateConnectorAssociationEnds – All associations typing a Connector must have the same number of associationEnds, which are the same as the number of relatedFatures of the Connector.
[Note: See the statement in 7.4.6.2 Connector Declaration on this.]

validateConnectorTypeFeaturing – If a Connector has an owningType or (non-implied) ownedTypeFeaturings, then each of its relatedFeatures must have some featuringType of the Connector as a direct or indirect featuringType.
[Note: This validation constraint corresponds to the semantic constraint checkConnectorTypeFeaturing, in the case that the semantic constraint is not able to be satisfied by adding implied TypeFeaturings.]

8.3.4.7.3 Expression
validateExpressionResultExpressionMembership – An Expression must own at most one ResultExpressionMembership.

8.3.4.7.4 Function
validateFunctionResultExpressionMembership – A Function must own at most one ResultExpressionMembership.

8.3.4.8.3 FeatureChainExpression

validateFeatureChainExpressionConformance – The featuringTypes of the targetFeature of a FeatureChainExpression must conform to the result parameter of the argument Expression of the FeatureChainExpression.

8.3.4.8.4 FeatureReferenceExpression

validateFeatureReferenceExpressionReferentIsFeature – The first Membership of a FeatureReferenceExpression that is not a ParameterMembership must have a Feature as its memberElement.

8.3.4.8.5 InvocationExpression

validateInvocationExpressionParameterRedefinition – Each input parameter of an InvocationExpression must redefine a feature of a type of the InvocationExpression.

validateInvocationExpressionNoDuplicateParameterRedefinition – Two different parameters of an InvocationExpression must not redefine the same feature of a type of the Invocationexpression.

8.3.4.8.14 OperatorExpression

validateOperatorExpressionCastConformance – If an OperatorExpression is for the cast operator (as), then the types of the result of the argument of an OperatorExpression must conform to the target types of the cast.

8.3.4.8.15 SelectExpression

validateSelectExpressionOperator – The operator of a SelectExpression must be “select”.

8.3.4.10.2 FeatureValue

validateFeatureValueOverriding – All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues.

8.3.4.12.3 MetadataFeature

validateMetadataFeatureMetaclassNotAbstract – The metaclass of a MetadataFeature must not be abstract.

validateMetadataFeatureAnnotatedElement – The annotatedElement of a MetadataFeature must have an abstract syntax metaclass consistent with the annotatedElement declarations for the MetadataFeature.

validateMetadataFeatureBody – Each ownedFeature of a MetadataFeature must have no declared name, redefine a Feature owned by a supertype of the MetadataFeature, either have no featureValue or a featureValue with a value Expression that is model-level evaluable, and only have ownedFeatures that also meet these restrictions.

7.4.1 (Kernel Overview) says

... data types cannot also be classes or associations, or share instances with them.

... data types classify things that do not exist in time or space ...

Clauses 8.4.4.2 (Data Types Semantics) and 8.4.4.3 (Classes Semantics) say:

The Type Base::DataValue is disjoint with Occurrences::Occurrence and Links::Link,

The Class Occurrences::Occurrence is disjoint with Base::DataValues

but Occurrence::Occurrence and Base::DataValue are not disjoint in the libraries.

Clause 9.2.5.1 (Objects Overview) says

Objects and Performances do not overlap

but Objects::Object and Performances::Performance are not disjoint in the libraries.

Clause 7.4.4 (Structures) says

Structures and behaviors do not overlap,

but there is no constraint for this.

The reflective KerML model in the Kernel Semantic Library has the following inconsistencies with the normative KerML abstract syntax:

1. The ReferenceSubsetting metaclass should be in the Core package, not the Kernel package.

2. The feature Succession::transitionStep should not subset ownedFeature.

In the last example of clause KerML 7.4.7.2 Behavior Declaration, at the top of page 157, there is the line

binding picture = focus.picture;

I assume this should be

binding picture = shoot.picture;

in order to be consistent with the declaration before.

The second line of the following does not parse:

abstract connector c1;
abstract connector c2 = c3; // Error: No viable alternative at input '='

The reason for this is that the NaryConnectorDeclaration production uses FeatureDeclaration (see KerML 8.2.5.5.1):

NaryConnectorDeclaration : Connector =
    FeatureDeclaration
    ( '(' ownedRelationship += ConnectorEndMember ','
        ownedRelationship += ConnectorEndMember
        ( ',' ownedRelationship += ConnectorEndMember )* ')' )?

However, however FeatureDeclaration does not include ValuePart, which provides the syntax for feature values (see KerML 8.2.4.3):

Feature =
    FeaturePrefix
    ( 'feature'? FeatureDeclaration
    | 'feature'
    | ownedRelationship += PrefixMetadataMember
    )
    ValuePart? TypeBody

On the other hand, KerML 7.4.6.2 states that “A connector is declared as a feature (see 7.3.4.2) using the keyword connector”, and a feature declaration (in the informal sense) can, in general, include a feature value, so it would be expected to be allowable for a connector, too.

Note that this is not a problem for item flows, which explicitly allows a ValuePart (KerML 8.2.5.9.2):

ItemFlowDeclaration : ItemFlow =
    ( FeatureDeclaration ValuePart?
      ( 'of' ownedRelationship += ItemFeatureMember )?
      ( 'from' ownedRelationship += ItemFlowEndMember
        'to' ownedRelationship += ItemFlowEndMember )?
    | ( isSufficient ?= 'all' )?
      ownedRelationship += ItemFlowEndMember 'to'
      ownedRelationship += ItemFlowEndMember

[From Vince Molnar] Clause 9.2.12.2.7 (universalClock), Description, says

universalClock is a single Clock that can be used as a default universal time reference.

but the Clocks library shows it as a package-level feature, ie, it has no featuring type, which Clauses 7.3.4.1 Features (Overview) and 8.3.3.3.3 (Feature) explain as

The domain of features with no explicit featuring types is the type Anything from the Base library model (see 9.2.2).

The domain of a Feature with no featuringTyps is implicitly the most general Type Base::Anything from the Kernel Semantic Library.

enabling everything in the universe (instances of Anything) to identify its own universal clock.

The phrase "universalClock is a single Clock" above is worded as if universalClock were a class, rather than a feature, giving the impression of exactly one value for universalClock across all things, but there is no constraint for this. Similarly, library documentation for Occurrence::localClock says:

By default this is the singleton universalClock.

The term "singleton" usually refers to instances of a class, rather than values of a feature, giving the impression of exactly one value for universalClock across all things.

Might be other features like this. For example, from the library:

Observation::defaultMonitor[1] : ChangeMonitor {doc
  /* defaultMonitor is a single ChangeMonitor that can be used as a default. * }

SpatialFrames::defaultFrame : SpatialFrame[1] { doc
  /* defaultFrame is a fixed SpatialFrame used as a universal default. */ }

These are also top-level features that seem intended to be "universal" in the sense above.

Clause 9.2.4.1 (Occurrences Overview), under Temporal and Spatial Associations, describes temporal/spatial relations between occurrences, such as HappensBefore/Outside and HappensDuring/InsideOf, then says:

The Links above to do not take up time or space, they are temporal and spatial relations between things that do (they are disjoint with LinkObject, see 9.2.5.1).

but

• Some links can be occurrences without being link objects (LinkObject specializes of Link and Object, but does not intersect them).

• Spatial links are not disjoint with LinkObject or Occurrence in the libraries.

In Clause 8.3.3.3.1 (Overview, Features Abstract Syntax), Figure 18 (Subsetting):

• Subsetting::/owningFeature:Feature[1] narrows the multiplicity inherited from Type::/owningType[0..1] in Clause 8.3.3.1.1 (Overview, Types Abstract Syntax), Figure 10 (Specialization).

• Redefinition::/owningFeature:Feature[0..1] subsets the above with the same name, which is not allowed, and widens the multiplicity back to the one on Type.

This prevents subsettings from being defined without "affecting" the specializing feature (ie, modifying that feature as a model element). Compare to Subclassification, which leaves the inherited multiplicity as is for this purpose, in Clause 8.3.3.2.1 (Overview, 8.3.3.2 Classifiers Abstract Syntax), Figure 16 (Classifiers).

Clause 9.2.3.1 (Links Overview) says

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

but the two places it appears in the Links model library

  readonly feature participant: Anything[2..*] nonunique ordered;

  feature participant: Anything[2] nonunique ordered redefines Link::participant;

do not include the "end" keyword (are not end features), to prevent the semantics of end features from applying to the participant feature (see KERML-37).

The property MetadataFeature::metaclass has multiplicity 0..1. Since it also redefines type, this means that a MetadataFeature can only have a single type, which must be a Metaclass.

In SysML, MetadataFeature is specialized to MetadataUsage, which is also a specialization of ItemUsage. MetadataUsage::metadataDefinition redefines MetadataFeature::metaclass, but its type is still Metaclass, with the intent that KerML Metaclasses, as well as SysML MetadataDefinitions, can be used to define SysML MetadataUsages.

However, the checkMetadataUsageSpecialization constraint requires that a MetadataUsage specialize the SysML library usage Metadata::metadataItems, which is typed by Metadata::MetadataItem. The base definition Metadata::MetadataItem specializes both Metaobjects::Metaobject from KerML and Items::Item from SysML.

This works without problem if a MetadataUsage is actually typed by a SysML MetadataDefinition. Since all MetadataDefinitions subclassify Metadata::MetadataItem, the single type of the MetadataUsage will be the specializing MetadataDefinition that is declared for it. However, if a MetadataUsage is typed by a KerML Metaclass that is not a subclassification of Metadata::MetadataItem, then the implied specialization of Metadata::metadataItems will result in the MetadataUsage implicitly having Metadata::MetadataItem as a type in addition to the declared Metaclass.

And this violates the multiplicity of MetadataFeature::metaclass.

Occurrence::localClock:Clock identifies a "time reference for this Occurrence" (9.2.4.2.13 Occurrence), but no feature is defined for a local spatial frame to identify a spatial reference for it (i.e., occurrences refer to a clock to measure time, but not a measuring rod for space).

In the BNF in 8.2.5.8.2 Primary Expressions, the PrimaryExpressionMember production is used in BracketExpression, IndexExpression, CollectExpression, SelectExpression and FunctionOperationExpression to parse a PrimaryExpression that is intended to be the initial argument of an InvocationExpression. However, the result of PrimaryExpressionMember is a FeatureMembership that directly owns the parsed PrimaryExpression. But this will not result in the PrimaryExpression being an argument of the containing InvocationExpression because, for that to happen, the Expression needs to be the feature value of a parameter of the InvocationExpression.

PrimaryExpressionMember should instead be structured like ArgumentMember in 8.2.5.8.1, resulting in a ParameterMembership to a Feature with a FeatureValue relationship to the parsed PrimaryExpression. NonFeatureChainPrimaryExpressionMember also needs to be similarly updated.

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 the libraries sometimes apply it to features with values that might be intended to change over the lifetime of an instance. For example, Clause 9.2.12.2.4 (Clock) says

A Clock provides a scalar currentTime that advances montonically over its lifetime.

but Clocks::(Basic)Clock::currentTime are readonly:

Clock { ...
  readonly feature currentTime : NumericalValue[1] {
    doc /* A scalar time reference that advances over the lifetime of the Clock. */ } ... }
BasicClock { ... readonly feature :>> currentTime : Real; }

Might be others, including features appear at the package level. For example, could check defaultClock, defaultMonitor, and defaultFrame in Clocks.kerml, Observation.kerml, and SpatialFrames.kerml, respectively.

The validateParameterMembershipParameterHasDirection constraint requires that the ownedMemberParameter of a ParameterMembership have a non-null direction – which is what makes it a parameter. However, it does not specify what the direction should be.

Now, for a ReturnParameterMembership, the validateReturnParameterMembershipParameterHasDirectionOut requires that the direction be out. The validateParameterMembershipParameterHasDirection should be updated so that, for a non-return parameter, the default direction is in.

When parsing the notation for AnnotatingElements that explicitly identify their annotatedElements, the corresponding Annotation relationships are owned by the AnnotatingElement. It would be convenient to have a property that subsets AnnotatingElement::annotation and Element::ownedRelationship that could directly hold these. Note that this cannot be called ownedAnnotations, because AnnotatingElement already inherits a property with that name from Element, which is for Annotations owned by annotated Elements, not AnnotatingElements. Perhaps the new property on AnnotatingElement could be called ownedAnnotatingRelationship.

The definition of Namespace::resolve seems to be missing a memberElement, otherwise namespace will never be a Namespace:

let namespace : Element = resolve(qualification) in
if namespace = null or not namespace.oclIsKindOf(Namespace) then null
else namespace.oclAsType(Namespace).resolveVisible(name) endif

Connector::isDirected is described as

For a binary Connector, whether or not the Connector should be considered to have a direction from sourceFeature to targetFeature.

which is circular. There are no other definitions. The semantics is not math/modeled. There is no textual syntax for it. What is intended to express? is it needed?

Subclause 8.1 defines typographical conventions to be used in the KerML metamodel. However, these are not being followed consistently throughout Clause 8 and Clause 9.

MOF constraints require that all associations be named. But none of the associations in the KerML abstract syntax model are currently named. They should all be given generated names.

Features successors and predecessors of Occurrence should be disjoint. Otherwise, the library would allow circular HappensBefore graphs. If HappensBefore is to be interpreted as a strict temporal ordering constraint (which is suggested by the current documentation in the library) or is supposed to capture causality relationships, such cycles could/should not be collapsed into time-coincident occurrences, always leading to unsatisfiable models.

The libraries have LinkObject disjoint with SelfLink, which classifies all links that have the same thing at both ends, preventing LinkObject from linking things to themselves.

The OCL for the checkConnectorTypeFeaturing constraint (see 8.3.4.5.3) uses the Feature::isFeatureWithin operation (see 8.3.3.3.3) to check that each relatedFeature of a Connector is "within" a featuringType of the Connector. Unfortunately, isFeatureWithin is currently specified to allow "downward nesting" of a Feature. For example, in the following:

classifier A {
    feature x;
    feature y {
        feature z;
    }
    connector c from x to y::z;
}

the Feature z is considered to be indirectly "featured within" the Classifier A. But this means that the Connector c is then considered to be valid, which it shouldn't be – a feature chain y.z should be required to be used instead of the qualified name y::z.

The arguments for specializesFromLibrary are sometimes single quoted and sometimes double quoted. Search on specializesFromLibrary(' and specializesFromLibrary(" to find them.

Some multiple specializations in the libraries might be intended to be intersections, including feature specializations. For example, quite a few in Performances.kerml:

step subperformances: Performance[0..*] subsets performances, suboccurrences;
expr subevaluations: Evaluation[0..*] subsets evaluations, subperformances;
step subtransfers: Transfers::Transfer[0..*] subsets transfers, subperformances;
step subtransfersBefore: Transfers::TransferBefore[0..*] subsets transfersBefore, subtransfers;

In Links.kerml:

assoc struct LinkObject specializes Link, Object ... { ... }
assoc struct BinaryLinkObject specializes BinaryLink, LinkObject {... }

Might be others. Sometimes this is modeled with sufficiency, for example in Occurrences::Occurrence::

feature all spaceTimeEnclosedOccurrences: Occurrence[1..*] subsets timeEnclosedOccurrences, spaceEnclosedOccurrences { ... }
feature all spaceTimeEnclosedPoints : Occurrence[1..*] subsets spaceTimeEnclosedOccurrences { ... }

If sufficiency isn't needed for other reasons, it could be replaced with intersection.