Further implementation work has identified problems with certain resolutions in Ballot #5 that urgently need to be corrected.

KERML_-57 Time and space life/slice/portion modeling patterns are missing

1. validateSubsettingConstantConformance – This constraint requires the subsettingFeature to be constant if the subsettedFeature is. However, a feature can only be constant if it is variable. But this makes invalid the reference subsettings of the ends of, e.g., a succession between constant features, because the ends of a succession cannot be variable (since a succession is not a kind of class).
2. validateSubsettingPortionConformance – This constraint requires the subsettingFeature to be a portion if the subsettedFeature is. But this makes invalid the reference subsettings of the ends of any connector between portion features, because end features cannot be portions.
3. validateRedefinitionDirectionConformance – For the purposes of this constraint, the direction of the redefinedFeature is considered relative to the featuringType of the redefiningFeature. However, this does not work if the redefiningFeature is a variable feature with an implied featuringType. (The OCL for the constraint is also wrong: featuringType should be redefiningFeature.featuringType.)
4. validateRedefinitionFeaturingType – This constraint checks that the redefiningFeature has a different featuringType than the redefinedFeature. However, for variable features with implied featuringTypes, this constraint will always be met, even for features with the same owningType, because the constructed featuringTypes will not be equal (even if semantically equivalent).

KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations

1. checkFeatureParameterRedefinition – The proposed OCL update fixes the problem stated in the issue, but then this breaks positional-argument notation, because there is no semantic constraint requiring implied redefinitions from the invocation parameters to the parameters of the invoked function. (Also, the OCL replacement snippet should have "implies" at the end.)

KERML_-59 OCL for checkFeatureParameterRedefinition is wrong

1. checkFeatureParameterRedefinition – In the proposed OCL, the expression for let i : Integer is syntactically incorrect, and, even if corrected by adding a closing parenthesis, would not return an integer, as required.

KERML_-132 Constructor invocation expressions are semantically inconsistent

1. ConstructorExpression::modelLevelEvaluable – This operation is redefined to make constructor expressions always not model-level evaluable. However, construction using the previous invocation-expression notation could be model-level evaluable, and this can be useful, e.g., for instantiating RiskMetadata::RiskLevel in a metadata usage.
2. validateInvocationExpressionOwnedFeatures – This constraint requires that all ownedFeatures of an InvocationExpression have direction in. However, in the textual notation grammar, certain classification and metaclassification expressions are parsed to OperatorExpressions (a kind of InvocationExpression with type references that become ownedFeatures without any indicated direction.

Make the necessary corrections

This resolution proposes to resolve the problems identified in the issue as follows:

KERML_-57 Time and space life/slice/portion modeling patterns are missing

1. validateSubsettingConstantConformance – Revise the constraint to apply only if the subsettedFeature is constant and the subsettingFeature is variable.
2. validateSubsettingPortionConformance – Remove the constraint.
3. validateRedefinitionDirectionConformance – Revise the constraint so that, if the redefiningFeature is variable, its owningType is used instead of its featuringTypes.
4. validateRedefinitionFeaturingType – Revise the constraint so that if the redefiningFeature and/or the redefinedFeature are variable, then their owningType is used instead of their featuringTypes.

KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations

1. checkFeatureParameterRedefinition – Revise the constraint so that, if the owningType is an InvocationExpression, the constraint still applies unless the feature has a non-implied ownedRedefinition (which will always be the case if the feature was parsed from a named argument list).

KERML_-59 OCL for checkFeatureParameterRedefinition is wrong

1. checkFeatureParameterRedefinition – Correct the constraint by invoking indexOf(self).

KERML_-132 Constructor invocation expressions are semantically inconsistent

1. ConstructorExpression::modelLevelEvaluable – Revise the operation to allow a constructor expression to be model-level evaluable if all its arguments are.
2. validateInvocationExpressionOwnedFeatures – Revise the grammar classification and metaclassification expressions so that a TypeReferenceMember is parsed as a ParameterMembership, which requires that its ownedMemberParameter have the direction in.

The resolution also makes minor corrections of errors in the OCL for the following operations and constraint, found while formulating the above changes:

• checkConstructorExpressionResultFeatureRedefinition
• InstantiationExpression::instantiatedType
• OperatorExpression::instantiatedType

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

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

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

Rename ItemFlow to Flow

This resolution proposes the following changes:

1. Language Description: Changes the terminology of "item flow" to "flow", "succession item flow" to "succession flow", "item" to "payload".
2. Concrete Syntax: Changes the BNF for flows, to reflect the abstract syntax changes below.
3. Abstract Syntax:
   • Changes ItemFlow to Flow and SuccessionItemFlow to SuccessionFlow, with corresponding updates to references elsewhere in the document.
   • Changes ItemFeature to PayloadFeature and ItemFlowEnd to FlowEnd, with corresponding changes to association end names.
   • Updates various constraint names and OCL, reflecting the abstract syntax updates.
4. Semantics: Updates the semantics for flows to reflect the abstract syntax changes above.
5. Semantic Model Library: Changes names of Transfers::Transfer::item, SendPerformance::sendItem, and AcceptPerformance::acceptedItem to payload.

The resolution also cleans up some inconsistencies in areas affected by the above revisions. In particular:

1. An alternative Identification ValuePart has been added to the BNF production PayloadFeature, allowing a payload declaration to have a feature value without having to have a specialization part. This actually was the intent previously.
2. The checkItemFlowSpecialization constraint has been split into checkFlowSpecialization and checkFlowWithEndsSpecialization. Previously, checkItemFlowSpecialization required an ItemFlow to specialize Transfers::flowTransfers only if the ItemFlow had no itemFlowEnds. But the proposed checkFlowWithEndsSpecialization constraint requires a Flow to specialize flowTransfers if it has any ownedEndFeatures. This change allows a Flow to be declared using regular "longhand" end feature declarations (rather than with FlowEnds parsed from the "shorthand" notation), while still being implied to be a kind of flowTransfer. (A similar change was already made for SysML FlowConnectionUsages in the resolution to SYSML2-597.)

This resolution also resolves the following issue:

• KERML_-24 Performance & Object self redefinition missing in specification document

8.4.4.9.4 Invocation Expressions states that:

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

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

Add ConstructorExpression

This resolution adds ConstructorExpression to replace the use of InvocationExpressions with constructor semantics. InvocationExpressions is then limited to invoking only Functions or Behaviors. It also adds InstantiationExpression as the abstract superclass of ConstructorExpression and InvocationExpression.

In order to allow more consistent parsing, the instantiatedType of a ConstructorExpression or an InvocationExpression (other than an OperatorExpression) is parsed as a member of the expression. An InvocationExpression is then required to specialize the instantiated type, as before. In a ConstructorExpression, however, it is the result that specializes the instantiatedType. Further, unlike an InvocationExpression, whose arguments are parsed as feature values of ownedFeatures of the expression itself, the arguments of a ConstructorExpression are parsed as feature values of ownedFeatures of the result of the ConstructorExpression. In this way, a value of the instantiatedType is "constructed" as the result of the ConstructorExpression, while the expression itself can still be typed as an Evaluation.

The concrete syntax for a constructor expression is similar to that of an invocation expression, but preceded by the keyword new. Special dispensation is provided to allow non-Function Behaviors to still be essentially "constructed" using an InvocationExpression, as before. That is, if the instantiatedType of an InvocationExpression is a Behavior that is not a Function, then the InvocationExpression is still typed by the Behavior, with its result bound to itself. This does not cause semantic problems, because it is acceptable to specialize a Performance of the Behavior to an Evaluation that returns itself (see the proposed language description text for examples of this usage).

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

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

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

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

Add the concept of variable features

This resolution introduces the concept of "variable features", which are features of occurrences whose values may vary over time. This is specified semantically by making the domain of a variable feature (i.e., its featuring type) the snapshots of its owning type, rather the owning type itself. Therefore, a variable feature can have different values on different snapshots of an occurrence, effectively "varying over time". The multiplicity of a variable feature is relative to each snapshot, rather than to the life of the occurrence.

A variable feature is notated in the concrete syntax using the new keyword var.

// An instance of a Vehicle is a Life by default.
struct Vehicle {
    // This feature has a single value for the Vehicle's life.
    //  It is not a feature of its timeslices or snapshots.
    feature id : VehicleId [1];

    // This feature can have a different single value on each snapshot of a Vehicle.
    var mileage : Distance [1];
}

A feature that is specified as variable can, nevertheless, be further specified as constant, meaning that it does not actually change its value over the duration of its featuring occurrence (this replaces the previous concept of "readonly"). This can be useful for asserting that a feature has values that are the same over only some of the time an occurrence exists, even though it could potentially vary at other times.

struct Vehicle {
    feature id : VehicleId [1];
    var mileage : Distance [1];

    portion parked :> timeSlices [*] {
        // When a Vehicle is parked, its mileage does not change.
        const :>> mileage;
    }
}

Updates to the abstract syntax to achieve these semantics include the following.

1. Add property isVariable to Feature. (isReadonly is renamed to isConstant.)
2. Remove the Featuring superclass of FeatureMembership and TypeFeaturing. Instead of FeatureMembership being a kind of Featuring, it implies TypeFeaturing in two different cases.
   • If isVariable = false, then FeatureMembership implies a TypeFeaturing relationship from its ownedMemberFeature to its owningType. This duplicates the current semantics for FeatureMembership.
   • If isVariable = true, then FeatureMembership implies a TypeFeaturing relationship from its ownedMemberFeature to a Feature representing the snapshots of its owningType. This Feature is an ownedRelatedElement of the implied TypeFeaturing, and it is constructed to redefine Occurrences::Occurrence::snapshots and be featured by the owningType of the FeatureMembership. This achieves the semantics of variable features.
3. Add operation isCompatibleWith to Type and Feature. For a non-Feature Type, isCompatibleWith is the same as specializes. A Feature, however, isCompatibleWith another Feature not only if it specializes the other Feature, but also if the two Features have a common redefinedFeature and the first Feature is accessible from a featuringType of the other Feature. This allows the snapshots featuringType of one variable Feature to be considered to semantically specialize the similar featuringType of another variable Feature, for the purposes of validation, without there having to be an actual Specialization relationship between them.

This resolution also resolves the following related issues:

• KERML_-47 Read only, misleading keyword, metaproperty name
• KERML_-154 Space and time slice descriptions are the same
• KERML_-159 n>2-ary link ends not readonly

In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

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

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

Exclude InvocationExpressions from the constraint

InvocationExpression is the only case in which the named-argument notation can be used and the checkFeatureParameterRedefinition constraint currently applies. But reordering parameters is actually safe in this case, because an InvocationExpression is to have a single function as its type, and an InvocationExpression cannot be the direct target of another InvocationExpression. So, the simplest solution to this issue is simply to exclude InvocationExpressions from the checkFeatureParameterRedefinition constraint. Allowing greater freedom for reordering parameters can be considered in other cases in the future, as a functionality extension, after more consideration.

The current abstract syntax for MetadataAccessExpression violates the rule that non-relationship metaclasses should only be (concretely) related by reified relationships. The property MetadataAccessExpression::referencedElement should be derived from such a reified relationship (like FeatureReferenceExpression::referent), rather than pointing directly to an Element.

Revise MetadataAccessExpression

This resolution makes the property MetadataAccessExpression::referencedElement derived. The actual Relationship to the referencedElement is then an ownedMembership that is not a FeatureMembership.

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

Add validation constraint

Agreed that there should be a validation constraint ensuring that an end feature can only be redefined by another end feature.

The current derivation constraint for AnnotatingElement::ownedAnnotatingRelationship is

ownedAnnotatingRelationship = ownedRelationship->
    selectByKind(Annotation)->
    select(a | a.annotatingElement = self)

Resolution KERML_-135 to KERML_-119 makes Annotation::annotatingElement derived, with the derivation

annotatingElement =
    if ownedAnnotatingElement <> null then ownedAnnotatingElement
    else owningAnnotatingElement
    endif

But Annotation::owningAnnotatedElement does not have its own derivation, but is, rather, determined as the inverse property to AnnotatingElement::ownedAnnotatingRelationship. This means that the derivations for AnnotatingElement::ownedAnnotatingRelationship circularly depend on each other and are, therefore, not well defined.

Update the derivation

The updates in the resolution to KERML_-119 ensure that an Annotation is owned either by its annotatingElement or by its annotatedElement. Therefore, checking that an Annotation is not owned by its annotatedElement is equivalent to checking that it is owned by its annotatingElement. And annotatedElement is not derived, so updating the derivation of ownedAnnotatingRelationship to use annotatedElement removes the circularity identified in the issue.

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

Add transitivity for time/space relations where it is missing

Other time/space associations missing transitivity are PortionOf, TimeSliceOf, and SpaceShotOf. Transitivity is already modeled for associations HappensBefore, HappensDuring, and InsideOf. The following are transitive, but it is unnecessary to model it:

• Association SnapshotOf, as long as TimeSliceOf transitivity is added, SnapshotOf will be also, due to sufficiency of its cross feature snapShotOf and specializing TimeSliceOf.
• Feature Occurrence::spaceTimeEnclosedPoints, because it has no other portions besides itself and is reflexive, it (indirectly) specializes timeSlices, see self.

Occurrences.kerml, within Occurrence, is revised to model transitivity for associations Within, WithinBoth, HappensWhile, SpaceSliceOf, SpaceShotOf, PortionOf and TimeSliceOf via their cross features spaceTimeEnclosedOccurrences, spaceTimeCoincidentOccurrences, timeCoincidentOccurrences, spaceSliceOf, spaceShotOf, portionOf and timeSliceOf, respectively, similarly to how it is currently modeled in successors, timeEnclosedOccurrences, and spaceEnclosedOccurrences (cross features of associations HappensBefore, HappensDuring, and InsideOf, respectively).

Occurrence::spaceEnclosedOccurrences is also revised to ensure occurrences inside another are outside occurrences that are outside the other.

There are some errors in the OCL of certain operations add to Feature by the resolution of KERML_-18.

1. In isCartesianProduct, the first two conditions should not be part of the first operand of the following "implies" (otherwise, e.g., a feature with no type or featuring types would incorrectly be considered a Cartesian product).
2. In isOwnedCrossFeature, "owningType" should be "owningNamespace" (because owned cross features are required to be not owned via FeatureMemberships).
3. In ownedCrossFeature, ownedMembers owned via FeatureValues should also be excluded from the list of ownedMemberFeatures being computed.

Correct operation OCL

Agreed.

The spec says "For an OwningMembership, the owningMemberName and owningMemberShortName are given by the Element name and shortName"

I think this should be ownedMemberName and ownedMemberShortName

<Note that this was found in Version 1.0, Beta 2.2>

Correct the wording

Agreed, this should be corrected.

In section 8.3.2.4.5 - the spec says
A Namespace can provide names for its members via the memberNames and memberShortNames specified by the Memberships in the Namespace.
However, the only subclass of Membership, OwningMembership redefines memberName, thus:
8.3.2.4.8:
/ownedMemberName : String [0..1]

Presumably this means that effectively memberName must equal ownedMemberName in OwningMembership.
There is no constraint to this effect and i can see it would be tricky, give the redefinition.
I wonder whether the metamodel needs a bit of surgery, given that the majority of Memberships are OwningMemberships and therefore have this issue.

No change

By UML semantics, redefining a property means that it replaces the redefined property in the redefinition scope. Therefore, in the case cited in the issue, there is no need for a constraint, because OwningMembership doesn't even have a memberElement property. The owningMemberElement property is the memberElement property in the context of OwningMembership. If an OwningMembership element is "upcast" to its Membership supertype, then accessing the memberElement is just the same as accessing owningMemberElement on the element considered as an OwningMembership.

Property redefinition is used extensively in this way in the KerML abstract syntax model (as it is in most MOF-based abstract syntax models).

[From Dr. Charles Manion] In 9.2.4.1 (Occurrences Overview), under Time and Space Slices, the first paragraph starts

Time slices are portions that include all the space of their larger Occurrences within a potentially smaller period of time than the whole Occurrence, ...

while the second paragraph starts

Space slices are portions that include all the space of their larger Occurrences, but not necessary all their time,

making it seem like time and space slices aren't different regarding space and time.

Merge with KERML_-57

The resolution of this issue is covered by the resolution to KERML_-57.

Links::Link:participants and their redefinitions BinaryLink::source/target are readonly, but links with more than two ends aren't required to be.

Merge with KERML_-57

This issue is effectively resolved by the resolution to KERML_-57.

Implementation of the resolution to KERML_-39 as approved has identified some needed corrections that need to be made:

1. The revision to the operation Type::directionOfExcluding is missing the functionality to switch in and out directions on features of a conjugated Type relative to its original Type.
2. In the OCL for the operation Type::visibleMemberships, self needs to be added to excluded in the call to inheritedMemberships.
3. In the OCL for the constraint Type::deriveTypeInheritedMembership, the call to inheritedMemberships needs to be updated to reflect the revised signature for that operation.

In addition, adding the operation allRedefinedFeatures to Membership is ill-advised, because it creates a dependency of a Root metaclass (Membership) on a Core metaclass (Feature), in violation of the intended layering.

Correct the identified problems.

Agreed.

Sorry, wrong taskforce. The issue should be closed no change.
scalarQuantities is defined as nonunique. However some of its subsets are not. They probably should be nonunique.

Examples:
width, height or gaugePressure

Also many don't have multiplicity [*]. As far as I know, this would not be necessary, because it is the default for attributes defined at package level anyway. However, length and scalarQuantities itself do have an explicit multiplicity. I guess it should be consistent.

Spurious issue

This issue has been refiled with the SysML v2 FTF.

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

Add appropriate semantic constraints

• Add a semantic constraint for SelectExpression capturing the expectation that the type of the result should be the same as the type of the result of the first argument expression (since the result values are necessarily a subset of the argument values), as suggested in the issue.
• Also add a new IndexExpression metaclass with a similar semantic constraint for index expressions using the using the operator #. Even though not mentioned in th issue, it is also expected that the type of the result of of an index expression is the same as the type of the result its first argument, at least if the result of the first argument is not an array (because, for an array, the index function '#' is specialized to return an element of the array, which will general be of a different type than the array itself).

package p {
    part b {
        part B;
    }
    part A :> b;
    e = A.? { }.B;
}

The pilot implementation creates implied subsetting for the select expression result parameter to specify more specific return type than Anything.
This is so that the select expression application on collection of objects of type X returns result of collection of type X objects

Duplicate of KERML_-117

This is a duplicate of KERML_-117.

package ShapeItems {
    part equals;
    item edges {
        item vertices;
    }
    assert constraint {
        in i;
        edges#(i).vertices->equals()
    }
}

The pilot implementation creates implied subsetting for the # expression result parameter to specify more specific return type than Anything.
This is so that the # operation application on Sequence of objects of type X returns result of type X.
But there is nothing about this in the specification at the moment.

Covered in resolution of KERML_-117

The resolution of KERML_-117 also resolves this issue.

typo in OCL, also on page 184

Correct references to ownedMemberParameter

The correction needs to be made in the OCL for deriveExpressionResult and deriveFunctionResult.

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

Correct the text

Agreed.

Certain primitive data types have have specified extents of values

two "have"s remove one

Remove redundant "have"

Agreed.

Problem:
Currently, there is no global scope operator specified. This makes it impossible to target an element in the global scope if an element with the same name exists in an intermediate scope.

We should be able to target an element in the global scope, even if an intermediate element has the same name.

Proposed Solution:
Introduce a global scope operator: $::

Example using the global scope notation:

$::'Port Example'::FuelOutPort::temperature

Add global scope notation

This resolution adds the proposed global scope notation to the concrete syntax and revises the name resolution rules to account for it.

7.3.4.1 (Features Overview) says

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

and 8.3.3.3.3 (Feature) says

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

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

Merge with KERML_-5

The resolution of KERML_-5 also covers this issue.

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

Correct productions

Agreed.

The description of the checkFeatureParameterRedefinition constraint is

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

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

Correct OCL

The OCL should be corrected to be consistent with the description.

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

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

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

Add isComposite semantics

This resolution adds

• informal semantics (in text) for single "ownership" via composite features (values of composite features cannot be values of other composite features that are not featured by the same composing instance).
• modeled semantics for the above and for the existing informal "destruction" semantics (values of composite features at the time their composing occurrences end also end at that time).

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

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

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

but

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

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

giving the desired result without introducing new associations for each transitionStep. This would also align it with SysML's modeling pattern specified in TransitionUsage::checkTransitionUsageSuccessionBindingConnector and checkTransitionUsageSourceBindingConnector.

Align TransitionPerformance modeling pattern with SysML::TransitionUsage

This resolution removes the associations between Succession and Step (Succession::transitionStep, triggerStep, effectStep, and guardExpression), most of which aren't referred to in the specification and none of which are referred to by constraints other their derivations (also removed). The modeling patterns described in Transition Performance's overview are modified to align with those for SysML's TransitionUsage (BindingConnectors instead of other Associations).

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

Merge with KERML_-57

This resolution to KERML_-57 also resolves this issue.

The resolution to KERML_-132 introduces a new ConstructorExpression. The textual notation for a ConstructorExpression has an argument list that is parsed like that of an InvocationExpression, into a set of parameters owned via ParameterMemberships, with the argument Expressions related to the parameters by FeatureValue relationships. However, for a ConstructorExpression, the argument parameters are not directly owned by the ConstructorExpression but, rather, by the result of the ConstructorExpression.

Unfortunately, the validateParameterMembershipOwningType constraint requires that the owningType of a ParameterMembership be a Behavior or a Step (an Expression is a kind of Step). This fails in the in the case of the proposed parsing for a ConstructorExpression, because its result Feature is not a Step.

Update the constraint

The simplest solution is to just update the validateParameterMembershipOwningType constraint to allow the use of ParameterMemberships within a ConstructorExpression.

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

Merge with KERML_-107

The resolution of this issue is covered by the resolution to KERML_-107.

Attributes
/owningType : Type {subsets type, redefines membershipOwningNamespace, type}

It is not "immediately" clear which 'type' metaproperty of which metaclass is the subsetted one, and which one is the redefined one. I think the semantics is meant to be that the redefines is for Featuring.type while the subsets is for the unnamed Association with the Type.featureMembership at it's other end.

KERML-22 already requests to name the Association, it should probably define the derivation rule for it's owned derived /type metaproperty... probably subsets membershipNamespace.. it may actually redefine membershipNamespace since only types can own FeatureMemberships

No change

The resolution to KERML_-57 makes this issue, as stated, moot, because, after that resolution, the identified property owningType only subsets one property named type. The more general issue of whether to include qualification in the naming of subsetted and redefined properties in the document is an editorial one that can be considered separately by the RTF.

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

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

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

Note: a similar issue will be raised on SysMLv2

Create UUID based on unique path

This resolution introduces the concept of a "path" for an element that is unique within the composition structure under a specific root namespace. This path can then be used instead of the qualified name to generate a distinct UUID for every element in a standard library model, not just the ones with non-null qualified name. The element path is constructed as follows:

1. If the element has a non-null qualified name, that is used as the path. This means that the UUIDs generated for elements with non-null qualified names will remain unchanged from previous versions of the normative library models.
2. If the element has a null qualified name and a non-null owning relationship, then its path is constructed from the path of its owning relationship by appending the character "/", followed by its position in the list of owned related elements of it owning relationship.
3. If the element is a relationship with a non-null owning related element (except for an owning membership as below), then its path is instead constructed from the path of its owning related element by appending the character "/", followed by its position in the list of owned relationships of it owning related element.
4. If the element is an owning membership whose owned member element has a non-null qualified name, then its path is constructed from the qualified name of its owned member element by appending the string "/owningMembership". Since owning memberships are one-to-one with their owned member elements, this allows owning memberships of named elements in library models to remain stable even if there is a reordering of member elements within the owning namespace.

The following shows some examples of element paths:

// Path of package: TopLevel
// Path of owning membership: TopLevel/owningMembership
package TopLevel {

    // Path of classifier: TopLevel::A
    // Path of owning membership: TopLevel::A/owningMembership
    classifier A;

    // Path of classifier: TopLevel::B
    // Path of owning membership: TopLevel::B/owningMembership
    // Path of owned subclassification: TopLevel::B/1
    classifier B specializes A;
        // Path of owning membership: TopLevel::B/2
        // Path of feature:  TopLevel::B/2/1
        feature;
    }

    // Path of owning membership: TopLevel/3
    // Path of classifier: TopLevel/3/1
    classifier {
        // Path of owning membership: TopLevel/3/1/1
        // Path of feature: TopLevel/3/1/1/1
        feature f;
    }
}

The resolution also revises the derivation for qualifiedName so that, if there are multiple owned members in a namespace with the same name, all but the first of these have a null qualifiedName. While the validateNamespaceDistinguishability constraint makes it invalid for a namespace to have duplicate names, the revised derivation for qualifiedName ensures that no two elements have the same qualified name, even for models that violate the constraint. This eliminates the possibility of different elements with the same qualified name getting the same generated UUID.

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

Correct the constraints

Agreed

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

Complete the OCL for inheritedMemberships and related operations

This resolution adds the OCL for Type::inheritedMemberships, and updates other related operations as necessary. The basic algorithm for computing inherited memberships of a type is as follows:

1. Collect the set of inheritable memberships, which are all non-private (i.e., public and protected) memberships of all direct supertypes of a type (see Type:: inheritableMembers). (This includes memberships inherited into those supertypes.)
2. Remove any inheritable memberships that are hidden due to redefinitions of their member elements (see Type::removeRedefinedFeatures).

In the second step, inheritable memberships are removed under either of two conditions:

1. The member element of the membership is one of the directly or indirectly redefined features of a member element of another inheritable membership.
2. The member element is a feature, one of whose directly or indirectly redefined features is directly redefined by an owned feature of the inheriting type.

The resolution also clarifies that the supertypes of a type include (see Type::supertypes):

• If the type is conjugated, then the original type from the conjugation.
• If the type is not conjugated, then the general types of all owned specializations.
• If the type is a feature with chaining features, then also the last feature in the chain (see Feature::supertypes).

This resolution also resolves the following issues:

• KERML_-84 Type::directionOf does not handle inheritence from feature chains
• KERML_-120 Recursive import with includeAll = true should recurse through private packages

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

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

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

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

Cross features owned by end features or their types

The proposed resolution introduces the concept of a cross feature of an end feature, which is specified using a new cross subsetting relationship between an end feature and its cross feature. The cross multiplicity of an end feature refers to the multiplicity of its cross feature, rather than the multiplicity of the end feature itself, which is always 1..1. The cross ordering and uniqueness of end features similarly refer to those of their cross feature.

The definition of HappensDuring from the Occurrences library cited in in the issue is revised as follows:

class Occurrence {
    ...
    feature timeEnclosedOccurrences : Occurrence [1..*];
    ...
}

assoc HappensDuring {
    end feature shorterOccurrence: Occurrence[1..1] crosses longerOccurrence.timeEnclosedOccurrences;
    end feature longerOccurrence: Occurrence[1..1];
}

Cross subsetting is identified by the crosses keyword. In this example, the multiplicity of shorterOccurrence is 1..1, while it's cross multiplicity 1..* is the multiplicity of its cross feature timeEnclosedOccurrences. That is, any instance of HappensDuring links exactly one shorterOccurrence to exactly one longerOccurrence (end multiplicity), while every Occurrence must be the longerOccurrence of one or more links (cross multiplicity).

The proposal also allows an end to alternatively have an owned cross feature for which the cross subsetting is implied. The cross multiplicity, ordering and non-uniqueness can then be declared directly on an end feature, with a notation that makes it clear that these are properties of the cross feature, not the end feature itself:

assoc HappensDuring1 {
    end [1..*] ordered nonunique feature shorterOccurrence: Occurrence[1..1];
    end feature longerOccurrence: Occurrence[1..1];
}

If no cross feature is given for an end, then its cross multiplicity is effectively 0..* by default.

By separating cross multiplicity from end multiplicity, this approach also removes the "special semantics" for end feature multiplicity by applying the same core multiplicity, uniqueness, and ordering semantics to both cross and end features. A pattern of implied relationships for the owned cross features of the ends of n-ary associations and connectors formalizes the semantics of cross multiplicity, uniqueness and ordering in those cases, too.

These proposed changes essentially restore distinctions available in SysML v1, but in a semantically cleaner way. The terminology is somewhat different, though.

• An end feature corresponds to a "participant property" in SysML v1, representing the participants in the links that are instances of an association. As for a participant property, an association end feature is always owned by its association. (Participant properties were introduced in SysML v1 and are not available in UML itself.)
• A cross feature corresponds to an "association end property" in UML (and SysML v1), in that the multiplicity, ordering and uniqueness of a UML association end semantically apply to "crossing" or "navigating" the association, rather than to the values of the property itself.
• An owned cross feature corresponds to an association end in UML that is owned by the association, rather than by the opposite related type.

This resolution also resolves the following related issues:

• KERML_-12 End feature multiplicity textual notation
• KERML_-13 Some bindings have optional connector end multiplicities
• KERML_-16 Association participant features, misleading term and textual keyword
• KERML_-17 Number of association end feature values, semantics
• KERML_-19 Context-dependent meanings for feature multiplicity, ordering, and uniqueness
• KERML_-20 Nary association end multiplicity, semantics
• KERML_-21 Association end features are not necessarily consistent with corresponding features of associated classifiers
• KERML_-28 Connector ends cannot give smaller lower multiplicity than their association ends
• KERML_-42 Association end feature description missing simple example and equivalence to related types

Annotation relationship creation modifies navigable AnnotatingElement::annotation property.

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

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

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

Revise abstract syntax for Annotation

It was not actually intended that the Annotation relationship for an AnnotatingElement every be owned within a different root Namespace than the AnnotatingElement. Indeed, the textual notation only allows two possible ownerships for an Annotation:

1. The Annotation is owned by its annotatedElement, in which case the annotatingElement is owned by the Annotation as an ownedRelatedElement.
2. The Annotation is owned by its annotatingElement.
   In both these cases, the Annotation and its AnnotatingElement are necessarily contained within the same root Namespace.

This proposal therefore retains the bidirectional annotation/annotatedElement association, but revises the abstract syntax so that the ownership of an Annotation is restricted consistently with the cases allowed in the textual concrete syntax.

1. Adds a composite ownedAnnotatingElement/owningAnnotatingRelationship association to explicitly model the case in which an Annotation owns its annotatingElement. (The case in which the Annotation is owned by its annotatingElement is already handled by the existing ownedAnnotatingRelationship/owningAnnotatingElement association.)
2. Makes Annotation::annotatingElement and AnnotatingElement::annotations derived from the other associations between Annotation and AnnotatingElement.
3. Adds validation constraints to Annotation that require an Annotation to be owned by either it's annotatedElement or its annotatingElement and, if it is owned by its annotatedElement, that is own its annotatingElement.

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

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

The line part g = f.a parses into:

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

Add semantic constraint checkFeatureChainExpressionResultSpecialization

It is agreed that there should be a semantic constraint for the purpose described in the issue. The similar existing constraint is actually checkFeatureFeatureReferenceResultSpecialization, which is a constraint on Feature. But it makes more sense for the new constraint to be directly on FeatureChainExpression, rather than being another constraint on the Core metaclass Feature that, nevertheless, supports Kernel semantics. Indeed, it also makes sense to move checkFeatureFeatureReferenceResultSpecialization from Feature to FeatureReferenceExpression.

So, this resolution does the following:

1. Replaces the existing constraint checkFeatureFeatureReferenceResultSpecialization on Feature with the constraint checkFeatureReferenceExpressionResultSpecialization on FeatureReferenceExpression.
2. Adds the new constraint checkFeatureChainExpressionResultSpecialization on FeatureChainExpression. However, this constraint cannot simply require that the result of a FeatureChainExpression specialize the targetFeature of the FeatureChainExpression, because that would not have the correct FeaturingType. Instead, it must specialize the specialized feature chain evaluated by the FeatureChainExpression, which is the chain of the first input parameter (the source parameter) of the FeatureChainExpression and the ownedFeature of that parameter (as returned by the operation FeatureChainExpression::sourceTarget()).
3. Adds the missing constraint validateFeatureChainExpressionOperator, requiring that the operator of a FeatureChainExpression always be '.'.

The abstract syntax for MultiplicityRange specifies that bound redefines ownedMember (see 8.3.4.11.2). However, the concrete syntax production for MultiplicityRange (see 8.2.5.11) allows it to have a TypeBody, which can include additional ownedMembers than the bounds. Indeed, the MultiplicityRanges declared in the Base library model have bodies with documentation comments, which are ownedMembers in addition to the declared bounds.

Update MultiplicityRange abstract syntax

1. Update the abstract syntax for MultiplicityRange so that bound subsets ownedMember, rather than redefining it.
2. Revise the derivation constraints for lowerBound and upperBound.
3. Add a derivation constraint for bound.
4. Add a validation constraint to ensure that the bound Expressions are the first ownedMembers of a MultiplicityRange.

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

For example, consider the model

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

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

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

Merge with KERML_-39

The resolution to KERML_-39 introduces a new Type::supertypes operation that is overridden in Feature to account for feature chains. This can be used to conveniently resolve KERML_-84. The update to the operation Type::directionOfExcluding necessary to do this is included in resolution KERML_-129 to KERML_-39.

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

The description of deriveExpressionResult states that

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

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

Somewhat similarly, the description of the constraint deriveFunctionResult states that

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

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

Revise the constraints

• Update the constraints deriveExpressionResult and deriveFunctionResult to select. ReturnParameterMemberships from featureMembership, rather than ownedFeatureMembership.
• Also similarly update the constraints validateExpressionResultParameterMembership and validateFunctionResultParameterMembership, to ensure that an Expression or Function has at most one ResultParameterMembership, owned or inherited.

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

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

Merge with KERML_-39

The resolution to KERML_-39 also resolves this issue.

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

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

package Namespace1 {
    classifier A;
    classifier B;
}

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

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

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

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

Require top-level imports to be private

Agreed.

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

Use name "featureTarget" instead

The name featureTarget can be used instead of targetFeature in order to avoid any conflicts.

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

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

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

Add derived property

Agreed

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

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

Revise the specification

The specification should be revised as suggested in the issue.

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

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

The bullets after this describe three elements for I.

Describe interpretation as 3-tuple

Change textual description of interpretation to describe it as a 3-tuple.

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

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

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

Restrict ends to have only a single type

One possible resolution to this issue would be to allow a Relationship to have multiple sourceTypes as well as multiple targetTypes. The sourceTypes property for a binary Association would then be derived as all the types of the first associationEnd, while the targetTypes would be all the types of the second associationEnd.

However, it seems more natural for a binary Association with two associationEnds to also be a binary Relationship between two relatedTypes (allowing that these may be the same Type). More generally, one would expect that an N-ary Association with N associationEnds to also be an N-ary Relationship between exactly N relatedTypes (allowing duplicates).

So, the proposed resolution is to add a validation constraint requiring that every associationEnd owned by an Association have exactly one type. Note allows, e.g., a redefining associationEnd to have a type that is more specialized than its redefined associationEnd, because the derivation of type results in the redefining associationEnd having only the more specialized type. However, it would not allow the redefining associationEnd to be declared with a type unrelated to the redefined associationEnd, because that would result in the redefining associationEnd having two types, its declared type as well as the type inherited from the redefined associationEnd.

The proposed constraint is currently violated by the Performs Association in the Performances library model. This is because Performs attempts to re-order the associationEnds redefined from the Involves Association it specializes. But this does not work because the checkFeatureEndRedefinition constraint still requires that the ends of Perform redefine the ends of Involves in order. The resulting implied Redefinitions to meet this constraint then result in the ends of Performs having two types (both Object and Performance_), violating the new validation constraint proposed in this resolution.

So, the proposed resolution also revises the declarations of Involves and Performs so that Performs does not violate the new validation constraint. (The proposed changes to the Performances library model are consistent with changes proposed in resolution KERML_-87 to issue KERML_-18, but can also be enacted separately if KERML_-87 is not approved.)

In 7.4.13 Metadata, the very last example is the declaration

#SecurityRelated #command def Save;

However, def is not a KerML keyword.

Correct the example

Agreed. The keyword should be behavior, as it is in the immediately preceding example.

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

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

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

Correct OCL

Correct the OCL for validateImportTopLevelVisibility as suggested.

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

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

Express interpretation function co-domain with cross products

The interpretation function is the power set of S, which is specified incorrectly, as described by the filer. Rather than complicate the current set builder notation, or attempt infinite cartesian products with index sets, use repeated cross products to express it. These are usually interpreted as specifying sequences of all the combinations of things of the specified types, as intended for S, even tho cross product is not associative and doesn't formally mean this.

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

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

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

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

Merge with KERML_-18

The proposed resolution to KERML_-18 rewords the first sentence of the paragraph in question, to clarify that the related types are exactly the types of the association ends.

Clauses 7.4.5 (Associations) and 8.4.4.5.1 (Associations) say

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

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

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

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

Merge with KERML_-18

This issue is resolved by the proposed resolution to KERML_-18.

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

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

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

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

Merge with KERML_-18

This issue is resolved by the proposed resolution to KERML_-18.

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

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

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

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

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

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

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

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

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

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

Merge with KERML_-18

The proposed resolution to KERML_-18 also resolves this issue, because the cross multiplicity moves to cross features, which are subsetted, but not redefined.

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

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

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

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

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

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

where Association::associationEnds identify participant features.

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

n-aries have this form:

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

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

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

Merge with KERML_-18

This issue is resolved by the proposed resolution to KERML_-18.

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

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

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

Clause 7.4.5 (Associations) says

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

Clause 8.4.4.5.1 (Associations) says

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

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

Clause 8.3.3.3.3 (Feature) says

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

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

Merge with KERML_-18

This issue is resolved by the resolution to KERML_-18.

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

Merge with KERML_-18

This issue is resolved by the proposed resolution to KERML_-18.

Type unioning, intersecting, and differing are described as

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

but this semantics is not math/modeled.

Add math semantics for Type union, intersection, and difference

Adds math semantics for Type union, intersection, and difference using first order logic and set operators, as the current Type math semantics does.

Background

Consider the flowing simple structure:

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

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

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

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

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

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

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

1. a connection from myEngine to leftRearWheel

2. a connection from myEngine to rightRearWheel

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

Concern

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

Proposal

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

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

This would not require a change in the abstract syntax.

Merge with KERML_-18

This issue is resolved by the proposed resolution to KERML_-18.

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

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

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

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

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

might be others.

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

Merge with KERML_-18

The proposed resolution to KERML_-18 removes the statements in question from this resolution and provides a semantics that allows a binding connector to have optional ends.

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

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

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

Make imports private by default

As stated in the issue, it makes sense to have the visibility of an Import default to private in the abstract syntax. However, it is still desirable to have the visibility of a Membership default to public. This inconsistency could be confusing to a modeler. Therefore, this resolution requires that the the visibility of an Import always be shown in the concrete syntax, even if it is the default visibility of private.

In addition, it is confusing that protected visibility is currently allowed for Imports, but is stated in the Language Description as being the same as private for Imports, even for the purposes of Specialization. Therefore, the resolution also removes that statement from the Language Description, explicitly allowing protected imported memberships. This also further permits a modeler to avoid public imports when only visibility to subtypes is desired, which is consistent with the intent of the issue to promote limited use of public imports.

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

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

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

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

Limit the recursion in recursive imports

It is agreed that it is sensible to limit the recursion for a recursive import to only owned Namespaces and to not include inherited Memberships from implicit Specializations. However, this resolution does not require that recursive imports be private. One of the uses of a filtered recursive import is to construct an effective "element groups" from elements selected by "flattening" the namespace hierarchy of some portion of a model, which requires that the filtered import be public. Further, if the resolution to KERML_-73 is adopted, making imports private by default, then this will reduce the risk that a modeler accidentally makes a recursive import public when this is not intended.

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

Add semantic constraint

It is agreed that there should be a semantic constraint as indicated in the issue. This should be a constraint on Feature, similar to the current checkFeatureResultSpecialization, which covers specifically the results of FeatureReferenceExpressions. (Note that this proposal is consistent with the proposed resolution KERML_-78 to KERML_-67.)

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

Correct the OCL

Agreed.

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

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

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

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

Allow "constructors" for Behaviors

Agreed.

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

No change

As shown in Figure 4, relationship is a non-navigable association end, the inverse to the association end relatedElement. As a non-navigable end, this property is owned by the association itself, not by the class at the opposite end of the association. Since the document otherwise only includes detailed descriptions of the metaclasses in the abstract syntax, not the associations, association-owned ends do not appear in any such descriptions. Navigable association ends, on the other hand, are always owned by the opposite class and, so, appear in the description of that class. This is why, e.g., there is a description of relatedElement in subclause 8.3.2.1.3 on the Relationship metaclass, but there is no description of relationship other than its appearance in Figure 4. Nevertheless, the relationship property is part of the normative KerML abstract syntax, as given in the KerML.xmi file, which is what Figure 4 depicts.

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

member binding f = e.result featured by T;

and the fourth snippet:

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

These are both syntactically incorrect. The correct syntax is:

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

and

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

Correct binding declarations

Agreed.

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

Correct the production

Agreed.

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

Fix the mapping

Handling of isOrdered and isUnique need to be added to the mapping.

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?

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

Clause 8.4.4.6.2 (Binding Connectors) says

binding f1 = f2;

is equivalent to

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

while the next clause, 8.4.4.6.3 (Successions) says

succession first f1 then f2;

is equivalent to

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

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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?

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

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.

Defer to RTF

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future RTF.

The execution algorithm in Annex A should could more cases.