The Concrete Syntax grammar defines the SINGLE_LINE_NOTE and MULTILINE_NOTE elements, but they are not used by the KerML grammar. Nor does the Concrete Syntax of SysML v2 use these elements.

The semantics, or intended use of these elements thus remain unclear, both in general, and with respect to the REGULAR_COMMENT element.

Clause 8.2.2.2 of the KerML specification defines the syntax for a
MULTILINE_NOTE element as follows:

---------------------------- Begin Quote -----------------------------
MULTILINE_NOTE =
'//' COMMENT_TEXT '/'
----------------------------- End Quote ------------------------------

The KerML specification does not contain any examples of multi-line note
elements, however.

The SysML specification does provide a single example of a multi-line
note element in the second code block of its clause 8.4.8.1, near the
top of page 410:

---------------------------- Begin Quote -----------------------------
//* Effective conjugated features:
out feature a subsets Base::things;
in feature b subsets Base::things;
inout feature c subsets Base::things;
feature d subsets Items::Item;
*//
----------------------------- End Quote ------------------------------

In contrast to the Concrete Syntax grammar given in the KerML
specification, which denotes '*/' (single slash) as the comment closer,
the example in the SysML specification uses '*//' (double slash) as the
comment closer.

It is thus ambiguous which of the two presented variants for closing
MULTILINE_NOTE elements is the correct one.

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.

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.

The first sentence of the first paragraph of the 7.4.5.3 section is "Association structures are both associations and structures (see 7.4.4 on structures), ", with an hyperlink on the 7.4.4 string. This reference is very far from the affirmation that Association structures are both Association and Structure.

I propose to use "8.3.4.4.1 Overview" or "Figure 26. Associations" in the "8.3.4.4 Associations Abstract Syntax" section, instead of it. It shows clearly the double relationship.

The first paragraph of the section begins with "Association structures are both associations and structures (see 7.4.4 on structures),", and an hyperlink points to the correct 7.4.4 section.

However, this reference is not useful. A more useful reference should be "8.3.4.4.1 Overview" or the "Figure 26. Associations" in the Association Abstract Syntax section which demonstrates that Association structures are both Association and Structure.

The following sentence looks suspicious with the use of the term 'front' instead of 'font' that is used associated with the 'code' font.

Similar stylistic conventions apply to text about KerML models, except that an "italic code" front is used.

It may be intentional to use the term "front", as it is a variation or a typeface of a specific font. But I doubt this is your intention because the term 'front' is not used in different dictionary or encyclopedic sources that I consulted. They are rather using italic or bold font, form or typeface.

2. Conugation (see 7.3.2.4 ) typo. it should be "Conjugation". The letter 'j' is lacking.

feature myStats : States

should be

feature myStats : Stats (i.e. no e in Stats)

deriveMetadataAccessExpressionReferencdElement not spelled correctly...

Referencd should be Referenced

checkConstructorExpressionResultDefaultValueBindingConnector not specified

Currently the only possibility to retrieve metadata of the model element is to use indicate element by specifying its (possibly qualified) name in conjunction with .metadata or meta SomeType syntax. During profile building there is a necessity to retrieve metadata of model element that is indicated (somewhat) dynamically – by navigating from current model element (given by annotatedElement). This is currently not possible.

Another use case is to check two stereotypes in the view expose filtering conditions. Currently the metadata is fed into the filtering conditions one by one, separately (thus if you have model element E with two metadatas applied: #M1 #M2, then filtering condition is invoked 3 times – once for the “primary” metadata of E, and once for each metadata application). And writing a filter which checks two stereotype applications is impossible as you need some facility to jump/navigate from one metadata to another

Thus:
1) Some operation or some syntactic structure shall be introduced that takes model element (as a metadata value) as input and returns it’s other metadatas. This operation is model-level evaluable.
2) Reference implementation shall be able to evaluate this operation – whether used in assert constraints or view expose filters
3) A test case in the conformance WG should check both cases – usage in assert constraints and usage in view expose filters

Example1 (assert constraints at meta level):

/**** Some domain library - e.g. UAF *****/

metadata def M1;
metadata def M2;

metadata def CheckOwnerStereo:> Metaobjects::SemanticMetadata{
	:>> annotatedElement: KerML::Type;
	assert constraint ownerMustBeM1 {
		RETRIEVEMETADATA(annotatedElement.owner) @M1;//check if owner is stereotyped by M1
	}
}

/****** User Model ******/

#M1 part def GoodParent {
	#CheckOwnerStereo part p1;//succeed
}
part def BadParent {
	#CheckOwnerStereo part p2;//fail
}

Example2 (view expose filters):

/*********User Model Example with Exposes ***********/
package Container {
	part def notStereotyped;
	#M1 part def singlyStereotyped1;
	#M2 part def singlyStereotyped2;
	#M1 #M2 part def doublyStereotyped;
}

view v {
	export Container::*;
	filter (RETRIEVEMETADATA(self @SysML::PartDefinition) @M1) and (RETRIEVEMETADATA(self @SysML::PartDefinition) @M2);//only pick up the doublyStereotyped
}

Expectation – make RETRIEVEMETADATA possible – by any syntactic means necessary

ControlFunctions::forAll() and exists() are currently not model-level evaluable.
This precludes their usage in profile building e.g. specifying constraints for MetadataDefinitions (aka “stereotypes”) of custom domains..
Thus:
1) These operations shall be model-level evaluable if and only if the inner predicate that they are using is model-level evaluable.
2) Reference implementation shall be able to evaluate meta-level assert constraints (that are defined against stereotyped model elements)
3) A test case in the conformance WG should check that constraints carrying such operations are (at least) mode-level evaluable (and evaluated by the tools that claim conformance);

Example:

    /**** Some domain library - e.g. UAF *****/

    constraint def StrategicRule;

    abstract metadata def SubjectOfStrategicRule :> Metaobjects::SemanticMetadata{
        :>> annotatedElement: KerML::Type {
            assert constraint onlyStrategicRules {
                ownedFeature
                    -> ControlFunctions::select { in x; x istype SysML::AssertConstraintUsage}
                    -> ControlFunctions::forAll { in y : KerML::Type; y.specializes(StrategicRule meta SysML::ConstraintDefinition) }
            }
        }
    }

    /****** User Model ******/

    #SubjectOfStrategicRule MyEnterprise {
        assert constraint strategy1 : StrategicRule; //valid
        assert constraint strategy2; //invalid - must specialize StrategicRule
    }

KerML spec declares (chapters 8.3.3.1.1, 8.3.3.1.10) that KerML::Type has some operations, which would be useful for building expressions in the user models. We have use cases where this is useful/necessary for profile building to specify baseType expressions in UAF.
More narrowly, the Type::specializes() operation is needed badly.
Unfortunately currently these operations are not accessible/available. The reason they do not work is that they are not provided/exposed in the KerML libraries and subsequently not implemented implemented/exposed in the reference implementation. KerML.kerml, Core::Type metaclass only declares attributes and not operations.
Thus:
1) Provided spec libraries shall expose more operations (at least Core::Type::specializes()). As a consequence the expressions using those operations shall become parseable. Operations shall be marked with model-level evaluability flag.
2) reference implementation should be able to evaluate such expressions.
3) A test case in the conformance WG should check this operation availability.
Example:

/**** Some domain library - e.g. UAF *****/

	part def SpecialContainedType;
	part def OrdinaryType;

	part def SpecialContainerType;
	
    metadata def DomainSpecificMetadata :> Metaobjects::SemanticMetadata {
		:>> annotatedElement : SysML::PartUsage;

        :>> baseType = 
				if ((annotatedElement.owner as KerML::Type).specializes(SpecialContainerType meta SysML::PartDefinition))
					?		SpecialContainedType meta SysML::PartDefinition 
					else	OrdinaryType meta SysML::PartDefinition;                
   }
   
/**** User model ******/

part def UserContainerPartFromSpecDomain :> SpecialContainerType {
	#DomainSpecificMetadata part specialUserPart;
}

#DomainSpecificMetadata part ordinaryUserPart1;

part def UnspecializedUserContainerPart {
	#DomainSpecificMetadata part ordinaryUserPart2;
}

/*
	The expectation is that specialUserPart specializes SpecialContainedType, while ordinaryUserPart1 and ordinaryUserPart2 specializes OrdinaryType.
	This is because baseType expression stipulates that parts inside SpecialContainerType-typed containers must have slightly different specializations
	The current behavior is that .specializes() invocation fails to compile.
*/

First paragraph is exactly the same text as the following section A.3.1 Overview

In 8.3.4.5.3 Connector, the constraint checkConnectorTypeFeaturing is intended to prevent a situation such as the following, when a related feature of a connector is not "featured within" the featuring type of the connector:

class C {
    feature x;
    feature y {
        feature z;
        connector x to z; // related feature "x" violates constraint
    }
}

However, if the connector and the related feature are both variable features, then the constraint is not violated:

class C {
    var feature x;
    var feature y : Occurrence {
        var feature z;
        var connector x to z; // no violation
    }
}

This was not intended. It happens because the constraint uses the operation isFeatureWithin which, for variable features, uses canAccess. The operation `canAccess` was changed to allow access in outer scopes, but this unintentionally resulting in a weakening of the checkConnectorTypeFeaturing constraint in regard to variable features.

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

classifier A;
classifier B;

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

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

feature y: B, A subsets x;

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

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

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

feature a1: A;
feature b1: B;

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

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

Clause 7.4.6.1 (Connectors Overview) says

Successions are binary connectors requiring their source and target features to identify Occurrences that are ordered in time.

and 8.4.4.6.3 (Successions) elaborates:

HappensBefore (see 9.2.4.2.1 ) has two associationEnds, asserting that the Occurrence identified by its first associationEnd (earlierOccurrence) temporally precedes the one identified by its second (laterOccurrence), which then also applies to Succession connectorEnds that redefine the associationEnds of HappensBefore.

but neither mention that occurrences identified by succession source/target features are not required to be temporally ordered unless succession end cross multiplicities properly restrict those inherited from HappensBefore's cross features, Occurrence::predecessors and predecessors, which are [0..*]. The clause continues with an example:

succession first f1 then f2;

is, with implied Relationships included, semantically 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 example does not restrict inherited succession end cross multiplicities, meaning occurrences identified by the connected features f1 and f2 are not required to happen in any particular order.

In the Kernel Semantic Library model TransitionPerformances, the behavior TransitionPerformance has a step accept that subsets Transfers::acceptPerformances, which is typed by Transfers::AcceptPerformance.

1. The step accept explicitly redefines the receiver parameter from AcceptPerformance. However, receiver is the second parameter of AcceptPerformance, but step does not redefine the first parameter payload. Therefore, accept::receiver also has an implied redefinition of payload, which is not intended.
2. The reason receiver is redefined is to bind with a feature value. However, this prevents the parameter from being redefined and rebound in further specializations. Unfortunately, this is exactly what happens in a SysML transition whose accepter has a via part.

In the Kernel Semantics Library model Transfers, the flow flowTransfers explicitly subsets transfers. However, transfers is also a flow, and it has owned end features. So, according to the constraint checkFlowWithEndsSpecialization, transfers is required to subset flowTransfers. This means transfers and flowTransfers subset each other and are, therefore, semantically equivalent. In addition, messageTransfers explicitly subsets transfers and, in similar fashion, also has an implied subsetting of transfers. As a result, all flows with implied subsetting of messageTransfers end up having the same semantics as flows with implied subsetting of flowTransfers.

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.

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

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

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

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

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

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.

Within this definition:

FunctionOperationExpression : InvocationExpression =
     ownedRelationship += PrimaryArgumentMember '->'
     ownedRelationship += InvocationTypeMember
     ( ownedRelationship += BodyArgumentMember
     | ownedRelationship += FunctionReferenceArgumentMember
     | ArgumentList )
     ownedRelationship += EmptyResultMember

InvocationTypeMember is not defined within the metamodel. According to Ed Seidewitz, this is a mistake in the specification and InvocationTypeMember should have been InstantiatedTypeMember.

In 8.3.3.3.4 Feature, in the OCL for the constraint checkFeatureFlowFeatureRedefinition, the reference to Transfers::Transfer::source::targetInput should be Transfers::Transfer::target::targetInput.

In the normative KerML.xmi file, each of the packages Connectors and Interactions has an association that owns both of its ends, one of which is named participantFeature. These associations are left over from TBD parts of earlier versions of the abstract syntax model. They should have been deleted. They do not appear in the specification document.

In the following places, the term "(connector) end multiplicities" has not been updated to "(connector) cross multiplicities":

• 9.2.9.1, p. 336
• A.3.3, p. 409 + 410
• A.3.7, p. 417

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.

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.

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

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.

In 8.3.2.4.5 Namespace, the description of the operation importedMemberships is:

Derive the importedMemberships of this Namespace as the importedMembership of all ownedImports, excluding those Imports whose importOwningNamespace is in the excluded set, and excluding Memberships that have distinguisibility collisions with each other or with any ownedMembership.

However, the OCL does not seem to cover the part about the exclusion of "Memberships that have distinguisibility collisions with each other or with any ownedMembership".

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

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.

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.

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.

The execution algorithm in Annex A should could more cases.

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

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

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

but this semantics is not model/mathed.

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

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.

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.

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

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

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.

Literal Values

inout

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

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

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

Clause 8.4.4.12.1 (Multiplicities, Semantics) says

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

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

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

• own a Multiplicity
• inherit them via unowned specializations

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

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

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

Example

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

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

example

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

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.

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

oclIsKindOf(Structure) = oclIsKindOf(AssociationStructure)

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

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.

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

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.

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.

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.

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.

Clause 9.2.9.1 (Control Performances Overview) says

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

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

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

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

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

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

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

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

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

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.

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.

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

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.

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?

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.

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.

(Note. The resolution to KERML_-57 changes isReadOnly to isConstant, but the lack of formal semantics remains.)

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.