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

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

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

Proposal:
Eliminate EndFeatureMembership and ParameterMembership from the abstract syntax.

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

There is a typo in checkFeatureObjectSpecialization:

ownedTyping.type->exists(selectByKind(Structure)) implies specializesFromLibary('Objects::objects')

The word "Libary" misses a "r".

Both of the constraints checkFeatureChainExpressionSourceTargetRedefinition and checkFeatureChainExpressionTargetRedefinition have OCL that starts with let sourceParameter : Feature = .... However, the rest of the OCL uses the name sourceTargetFeature. In both cases, the name declared in the let clause should be sourceTargetFeature.

In subclause 7.3.4.2, one but last paragraph, under point 4. composite or portion, the first bullet contains the following editorial mistake:

The sentence "Values of a composite feature also cannot be values of another composite feature that is not on the same instance of the feature's domain." appears twice, so one should be deleted.

Neither the operation Type::isCompatibleWith (in 8.3.3.1.10 Type, under "Operations", nor its redefinition Feature::isCompatibleWith (in 8.3.3.3.4 Feature, under "Operations") have a return type specified. Both should have return type Boolean.

The list of keywords on page 80 does not include the keywords 'standard' and 'library'.
Nevertheless, these keywords are throughout the text referenced as keywords, e.g., on 73, buttom.
Also, they are written in bold letters to indicate that they are keywords.

In subclause 9.2.7.2.9 on Transfer, the documentation of feature isInstant incorrectly uses isInstance. This should be replaced with isInstant.

The same typo occurs in standard library Transfers.kerml, so should be corrected there as well.

In the OCL for deriveFeatureFeaturingType, in the expression "featuring.type->asOrderedSet()", the property featuring no longer exists. The property typeFeaturing (opposite of TypeFeaturing::featureOfType) should be used instead.

The OCL for constraint checkFeatureParameterRedefinition uses the OCL indexOf operation to compute the index of a feature as an owned parameter of its owningType. However, according to the OCL specification, the result of this operation will not be defined if the feature is not actually in the list of owned parameters of the owningType. This should therefore be checked before the operation is called.

(In addition, the OCL is missing two close parentheses: one in at the end of line 7 "not ownedRedefinition->exists(not isImplied))" and one in line 19 after "oclIsKindOf(ReturnParameterMembership))".)

The description of the constraint checkMultiplicityTypeFeaturing begins "If the owningType of a Multiplicity is a Feature...". However, a Multiplicity is never owned via a FeatureMembership, so it cannot have a non-null owningType. The constraint should use owningNamespace instead of owningType (in the description and the OCL).

In the Kernel Semantic Library model Occurrences, the feature Occurrence::surroundedByOccurrences has a single nested end feature

end [1] feature surroundingSpace: Occurrence subsets self;

However, the cross multiplicity is invalid here, because constraint validateCrossSubsettingCrossFeature requires that the owningType of an end feature with an owned cross feature have at least two ends. Indeed, it is not clear why this feature should be an end feature at all.

In 7.4.7.2 Behavior Declaration "A behavior is declared as a classifier ...". But in the Metamodel a Behavior is a Class (8.3.4.6.1 Overview and 8.3.4.6.2 Behavior).

In KerML 9.2.4.2.13 Occurrence, the documentation for isDispatch says

isDispatch : Boolean

Determines whether the same incoming transfer can be accepted more than once by StatePerformances
composed under dispatchScope. It defaults to true for Performances, and false for other Occurrences
(including Objects).

However, this is potentially misleading compared to the definition of isDispatch in 9.2.11.1 State Performances Overview, which says:

isDispatch being true prevents the same Transfer from being accepted more than once by StatePerformances composed under dispatchScope, and prevents from being accepted at all any acceptable Transfers that are not accepted and are higher in incomingTransferSort order than the one that is. It defaults to true for Performances, including StatePerformances, and false for other Occurrences, while dispatchScope defaults to thisPerformance for StatePerformances, the top Performance (indirectly) composing the StatePerformance (see 9.2.6.2.14 ), and self for other Occurrences (see 9.2.2.1 ).

We should correct this to be consistent.

The wording in section 9.2.4.2.13 Occurrences seems to indicate that isDispatch=true would indicate transfers "can be accepted more than once" in contradiction with 9.2.11.1

The following library models include the declaration of types that have inherited members with the same name, because of diamond inheritance of redefined features.

Kernel Semantic Library

• FeatureReferencingPerformances
• Objects
• Observation

Kernel Function Library

• VectorFunctions

The constraint checkIndexExpressionResultSpecialization requires that

The result of an IndexExpressionmust specialize the result parameter of the first argument of the IndexExpression, unless that result already directly or indirectly specializes the DataType Collections::Array from the Kernel Data Type Library.

This excepts the case of indexing Arrays from the general specialization requirement. However, the indexing function '#' is specialized in the Kernel Functions Library model CollectionFunctions for all kinds of Collections, not just Arrays.

According to 8.4.4.9.6 Operator Expressions, under "Control Functions":

Given the above, a FeatureChainExpression of the form

src.f

(where src is an Expression) is semantically equivalent to the Expression

expr : ControlFunctions::'.' subsets Performances::evaluations { 
    feature redefines ControlFunctions::'.'::source = src {
        feature redefines ControlFunctions::'.'::source::target 
            redefines f;
    }
    alias for f;
    return subsets source.f;
}

Note that the redefining feature for ControlFunctions::'.'::source::target also redefines the feature f. However, according to the constraint validateRedefinitionEndConformance (see 8.3.3.3.8 Redefinition), if a redefinedFeature is an end feature, then the redefiningFeature must be, too. But this prevents an end feature from being used as the target (i.e., f above) of a feature chain expression.

This is particularly problematic, because, in the Kernel Semantic Library model StatePerformances, the declaration of StateTransitionPeerformance::transitionLinkTarget has the feature value transitionLink.laterOccurrence, which is a feature chain expression that targets the end feature laterOccurrence.

The semantic constraint checkMultiplicityTypeFeaturing (once corrected per KERML_-236) requires that the multiplicity of a Feature have the same featuringType as the Feature. However, if the Feature is an owned cross Feature, then it's featuringType is required to be the type of the opposite end Feature (for a binary association, or a Cartesian product type for an N-ary association). But, if a bound expression of an owned cross Feature is a FeatureReferenceExpression, one would expect the Feature name to be resolved in the context of the containing Association or Connector, as for an end Feature multiplicity. This requires that the featuringType of the multiplicity of an owned cross Feature be that of the end Feature, not the cross Feature.

If an end feature has a feature value, then it will have an implied binding connector between itself and the result of the feature value expression. However, if this is its first non-feature-value owning membership, then the operation Feature::ownedCrossFeature will return it as the owned cross feature of the end feature. Clearly this should not be the case.

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

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

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

The semantic constraint checkFeatureReferenceExpressionBindingConnector requires that a FeatureReferenceExpression have an implied BindingConnector between its referent and its result. However, since the FeatureReferenceExpression owns its result parameter, but the referent will be outside the expression, the defaultFeaturingType of the implied BindingConnector will be null. This means that the checkConnectorTypeFeaturing constraint cannot be satisfied for the BindingConnector as specified.

Line 124 in sysml.library/Kernel Libraries/Kernel Semantic Library/StatePerformances.kerml requires that transitions happen after the nonDoMiddle steps of their source StatePerformance:

private succession transitionLinkSource.nonDoMiddle[*] then Performance::self[1];

Lines 43 and 34 of States.sysml assert that user-defined substates subset nonDoMiddle, resulting in transitions not starting until all the subsates of the transition's source state have finished.

Since transition performances include the evaluation of the trigger and the guard, transitions cannot be taken until all the substates finish.

This goes against the general semantics of state machines, where substates are "interruptable," i.e., transitions leaving the parent state will deactivate substates as well. Note that the notion of "run to completion" only requires the complete processing of an event before dispatching the next one, where "processing" generally means the steps until reaching a stable state configuration, but not waiting in the new states.

The desired behavior would be that transitions start after the complete initialization of a stable state configuration (which most likely consists of all the entry actions of the new state configuration).

Additionally, line 124 is misaligned with the description in KerML 9.2.11.1:

StateTransitionPeformances require their guards to happen after the nonDoMiddle Step of the transitionLinkSource (all the middle Performances except for do) (...).

In fact, the library now requires the whole StateTransitionPeformance to happen after the nonDoMiddle, which technically includes the guard, but is stronger.

Referring to UML 2.5.1 section 14.2.3.4.5 "Entering a State", it says:

The semantics of entering a State depend on the type of State and the manner in which it is entered. However, in all cases, the entry Behavior of the State is executed (if defined) upon entry, but only after any effect Behavior associated with the incoming Transition is completed. Also, if a doActivity Behavior is defined for the State, this Behavior commences execution immediately after the entry Behavior is executed. It executes concurrently with any subsequent Behaviors associated with entering the State, such as the entry Behaviors of substates entered as part of the same
compound transition.

(Emphasis Added)

To be consistent with the expectations from the UML specification, we want to update KerML to ensure that the StatePerformance::doAction always occurs immediately after the StatePerformance::entryAction

As document in 8.3.3.1.10 Type for the operation removedRedefinedFeatures, an otherwise inheritable Membership is removed from the inheritedMemberships of a Type if either of the following conditions holds:

1. The memberElement of the Membership is included in redefined Features of another Membership in [the inheritable] memberships.
2. One of the redefined Features of the Membership is a directly redefinedFeature of an ownedFeature of this Type.

But consider applying this rule to the following model:

classifier A {
    feature x;
}
classifier B :> A {
    feature :>> A::x;
}
classifier C :> A, B {
    feature :>> A::x;
}
classifier D :> B, C;

Clearly, in classifiers B and C, the feature A::X is not inherited, because it is directly redefined by an owned feature of the classifier. Moreover, in classifier C, B::x is also not inherited, because B::x redefines A::x, and A::x is directly redefined by an owned feature of C. In classifier D however, both B::x and C::x are inherited. This is because C::x does not actually have a redefinition relationship with B::x, so the first condition of the removeRedefinedFeatures rule does not apply. As a result, D will inherit two redefinitions of x, which is semantically inconsistent and will violate the constraint validateNamespaceDistinguishibility.

This seems in itself potentially anomalous for user expectations. However, there is a more concerning impact when implied specializations are involved. For example, suppose the specialization by C of A and the specialization by D of B are both implied relationships. Since C also specializes B, and B is a supertype of A, according to 8.4.2 Semantic Constraints and Implied Relationships, the implied specialization of A can be considered redundant and not included – and similarly for the implied specialization by D of B. But it is only permitted, not required, that redundant implied relationships be removed. This means that, if a tool removes the implied specializations of A and B, then D is valid, but, if it does not remove them, then D is invalid, which is problematic.

In the KerML standard library for Triggers.kerml, the "TriggerAfter" function returns a TimeSignal by calling TriggerAt with an expression that involves "clock.currentTime". However, this binds the value of the TriggerAt "timeInstant" to an expression involving a "var" feature (currentTime).

The unfortunate result of this is that the value of the resulting TimeSignal is continuously changing !

return signal : TimeSignal[1] = TriggerAt(clock.currentTime + delay, receiver, clock, monitor);

Instead, we likely want to "capture" the value of "currentTime" using an initial value as of when the TriggerAfter is called to start observing the trigger rather than an ongoing binding.

private feature referenceTime : NumericalValue := clock.currentTime;

return signal : TimeSignal [1] = TriggerAt(referenceTime + delay, receiver, clock, monitor);

The resolution to KERML_-224 revised the constraints for ConstructorExpressions so that such expressions are model-level evaluable if their arguments are. However, subclauses 7.4.9.1 Expressions Overview and 8.4.4.9.8 Model-Level Evaluable Expressions were not revised to account for this.

[From Dr. Charles Manion] SpatialItem (eventually) specializes KerML Body, which are required to be 3 dimensional (innerSpaceDimension=3), but the "shapes" in ShapeItems.sysml are all lower dimensional (Curves and Surfaces, innerSpaceDimension=1 and 2, respectively). Since SpatialItem defines coordinates, it would be contradictory to give shapes (and Points, innerSpaceDimension= 0) coordinates.

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

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

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

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

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

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

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

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

To summarise:

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

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

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

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

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

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

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

assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...

aligning with the disjointness justifications above.

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

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

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

assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...

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

Consider the following example:

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

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

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

Some questions that highlight the meaning of this interpretation:

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

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

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

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

In this case, the extents would look like this:

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

Answers to the above questions change:

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

There are special rules for the effective naming of PerformActionUsages and ConstraintUsages owned via RequirementConstraintMemberships. These rules are specified normatively by the redefinitions of the namingFeature operation in 8.3.17.14 PerformActionUsage and 8.3.20.4 ConstraintUsage. However, this is not discussed in the Language Description clause, neither in 7.17.6 Perform Action Usage no 7.21.2 Requirement Definition Usage.

The OCL operation Namespace::importedMemberships computes the importedMemberships of a Namespace by calling the importMemberships operation on each of the ownedImports of the Namespace. This operation is redefined for Packages so that, if the Package has filterConditions, then any potentially imported Memberships are filtered out if it does not meet any of those conditions.

However, the Import::importMemberships operation, as specified for both MembershipImport (when recursive) and NamespaceImport uses the Namespace::visibleMemberships operation, not the importedMembership operation. The visibleMemberships operation in turn uses the Namespace::membershipsOfVisibility operation to collect both owned and imported Memberships of the proper visibility. But the membershipsOfVisibility operation is inherited by Package and not redefined.

As a result of this, when importing from a Package with filterConditions, the filterConditions are not applied when determining visible importedMemberships re-exported by the Package. In particular, a filtered import of the form "import Pkg::*[condition];" is parsed as an import of an anonymous package that owns the condition, but, with the current formal specification, the filtering will not actually be applied in this case.