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

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

In Links.kerml:

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

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

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

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

Add intersection to some multiple specializations

For specializations in the libraries that should be also be intersections, after the list of specialized types, insert intersects followed by the same types.

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

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

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

Correct checkConnectorTypeFeaturing constraint

The problem is actually worse than indicated in the issue. The OCL for Feature::isFeaturedWithin currently references feature.featuringType. This was probably intended to be self.featuringType (in which case it would operate as indicated in the issue description). However, as it is, the operation actually does not check the featuringType of a Feature, it checks the featuringTypes of the nested features of a Feature, which doesn't even really make sense.

In addition, since the semantics of type featuring is that the domain of a Feature is the intersection of its featuringTypes, the quantification over featuringTypes should use forAll rather than exists.

8.3.2.3.4 Comment Attributes shows a locale, but it can't be accessed through the 8.2.3.3.2 declared textual notation

Add "locale" to Comment notation

It should be possible to specify the locale in the textual notation for a comment (including a documentation comment).

The interaction FlowTransferBefore in the Transfers library package specializes both FlowTransfer and TransferBefore. Both FlowTransfer and TransferBefore are binary, so FlowTransferBefore has to be, too. However, in the normative Transfers.kerml file from the Kernel Semantic Library project, FlowTransferBefore is currently declared without owned end features, so it inherits two ends each from FlowTransfer and TransferBefore, for a total of four, which is incorrect. Instead, it needs to declare two nested end features that redefine the corresponding ends from each of the interactions it specializes.

(Note that, in subclause 9.2.7.2.3 of the specification document, FlowTransferBefore is actually documented as properly having two owned ends.)

Add end features

Agreed. In addition, messageTransfers and flowTransfers have a similar problem. The documentation in 9.2.7 Transfers also needs to be updated to be consistent with the normative Transfers.kerml model.

Third Paragraph

disjoining disjoint Person::parents from Person::children {
	doc /* No Person can be their own parent. */
}

The documentation does not reflect the actual disjoining being performed.
The disjoin separates a person's parents set from that person's children set.
Thus the disjoin is not about the person himself
Either fix the documentation to say "A person's parents can't also be their children, and visa versa."
or fix the disjoining
disjoining disjoint Person::self from Person::parents

Change the documentation on the example

Technically, the comment in the example is correct, if, as one would expect, the feature Person::parents is the inverse of Person::children (it is actually shown as such in a later example in subclause 7.3.4.7). This is because, if a Person where their own parent this would imply that they were also there own child, which would violate the declared disjointness.

But there is no point in being so subtle in the case of this example! It is less confusing to just change the documentation comment to "No Person can have a parent as a child or a child as a parent."

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

Use single quotes in OCL strings

OCL does, indeed, require the use of single quotes around strings (see OCL 2.4 specification, 7.4 and 9.3.20).

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

Remove disjointness of SelfSameLifeLink from Occurrence

Disjointness of LinkObject from SelfLink was removed by KERML-253 resolving KERML-231, but this was only because it was redundant, due to SelfLink specializing SelfSameLifeLink, which is declared disjoint with Occurrence (a generalization of Object). This resolution removes the disjointness of SelfSameLifeLink from Occurrence to enable (binary) link objects to identify the same thing on both ends.

KerML provides measuring devices for time (clocks), but not space ("measuring rods").

Close

The KerML Semantic Library actually does provide SpatialFrames for "measuring" positions in space.

The production MetadataFeature in 8.2.5.12 Metadata Concrete Syntax does not provide for the use of user-defined keywords, even though nested metadata feature annotations are allowed. (Note that the production Metaclass does allow user-defined keywords to be used on metaclass definitions.)

Allow user-defined keywords on metadata features

MetadataFeatures should be allowed to have user-defined keyword annotations.

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

Occurrence::successors and predecessors are (effectively) disjoint

Features Occurrence::successors and predecessors are inverses, so the only way two occurrences could "point at" each other (making the features non-disjoint) would be if the two occurrences are the same one, that is, the features are (at least partially) reflexive, but they both subset withoutOccurrences, which is irreflexive:

 feature successors: Occurrence[0..*]
   subsets withoutOccurrences
   inverse of predecessors { ... }

feature predecessors: Occurrence [0..*]
   subsets withoutOccurrences { ... }

feature withoutOccurrences: Occurrence[0..*]
     unions successors, predecessors, outsideOfOccurrences
     inverse of withoutOccurrences { ...
  /* withoutOccurrences is irreflexive. */
  inv { (that as Occurrence) != (that.that as Occurrence) } }

Package Interactions TBD should not be included in the KerML.xmi file.

Remove package "Interactions TBD"

Agreed.

If you look at the following sample:

1 a = 2 ^ 3 ^ 4;
2 a = (2 ^ 3) ^ 4;
3 a = 2 ^ (3 ^ 4);

Both lines 1 and 2 will generate the same model in SysML v2 pilot implementation.
This means that exponentiation operator seems to be left-associative, which is unusual, as exponentiation is supposed to be right-associative.

Make exponentiation right-associative

Exponentiation should be right-associative.

First Sentance of Last Paragraph
"If any of the types of a feature are data types, then all of them must be."
This is inconsistent with the Abstract Syntax that does not enforce this constraint, it enforces a weaker constraint.
Features that are types by DataType can legally be typed by Classifiers according to 8.4.4.2 semantics
8.4.4.2 Data Types Semantics states that DataType is disjoint with Class and Association,
so a more consistent statement would be that then
"If any of the types of a feature are DataTypes, then it can't also be typed by Class or Associations.

Revise the language description

Agreed.

In addition, the following statement in 7.4.3 Classes is also incorrect: "If any of the types of a feature are classes, then all of them must be." As noted in 8.4.4.3 Classes Semantics, the base Class Occurrences is disjoint with the base DataType DataValues, but not the base Association Link. So, the correct statement in 7.4.3 is "If any of the types of a feature are classes, then none of its types can be data types."

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

Add association names

Agreed.

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

Update Clauses 8 and 9

Clauses 8 and 9 need to be updated to follow the conventions.

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

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

Revise the validateParameterMembershipParameterHasDirection constraint

A better approach than suggested in the issue is to define an operation parameterDirection() on ParameterMembership and then revise the constraint so that it requires the direction of the ownedParameterMember to be equal to the result of parameterDirection(). The operation can then be specified to return in for ParameterMembership, but redefined to return out for ReturnParameterMembership. No additional constraint is then required to enforce this on ReturnParameterMembership.

Comment indicates that this should be Subclassification

Correct constraint deriveClassifierOwnedSubclassification

Agreed.

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

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

Correct OCL for Namespace::resolve

Agreed.

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

Add ownedAnnotatingRelationship property

Agreed.

Connector::isDirected is described as

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

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

Remove isDirected

Connector::isDirected is not needed. It can be removed.

Consider the following:

classifier A {
    in feature f;
}
classifier B conjugates A;
classifier C specializes B;

The feature f is an input of A, but an output of B. However, f will again be considered an input of C, which is not what one would expect.

The reason for this is that, as currently specified in 8.3.3.1.10 Type, the deriveTypeInput and deriveTypeOutput constraints only flip the inputs and outputs of a type if it is directly conjugated. Otherwise, the derivations just check the direction property of the features of the type, whether they are owned or inherited.

Correct the derivation of Type::input and output

Rather than simply flipping the inputs and outputs on conjugation, it is necessary to generally search upward in the supertype hierarchy to see if the direction of a feature is conjugated (possibly more than once). This can be done in the directionOf operation (allowing for the possibility of circular specializations), with input and output then derived as being collected from the features of a Type with the correct direction based on directionOf.

The validateMultiplicityRangeBoundResultTypes constraint requires "The results of the bound Expression(s) of a MultiplicityRange must be typed by ScalarValues::Natural from the Kernel Data Types Library." However, multiplicity bounds are often given by literals, and the result type of LiteralInteger is actually Integer, which does not conform to Natural.

Update the validateMultiplicityRangeBoundResultTypes constraint

Agreed. However, if a bound is model-level evaluable, then it can still be checked to have a non-negative value.

In the EBNF for MetaclassificationExpression:

MetaclassificationExpression : OperatorExpression =
    ownedRelationship += MetadataArgumentMember
    ( operator = MetaClassificationTestOperator 
      ownedRelationship += TypeReferenceMember
    | operator = MetaCastOperator owendRelationsip += TypeResultMember
)

The last line should be "ownedRelationshp" and not "owendRelationsip" in the EBNF.

In the EBNF for IndexExpression:

IndexExpression : OperatorExpression =
ownedRelationship += PrimaryExpressionMember
operator = '#'
'(' ownedRelationsip += SequenceExpressionListMember ')' 

The last line should be "ownedRelationshp" and not "owendRelationsip" in the EBNF.

Correct textual BNF productions

Agreed.

The disjointness of LinkObject in Objects.kerml

abstract assoc struct LinkObject specializes Link, Object disjoint from SelfLink, SelfSameLifeLink, HappensLink

is redundant because SelfSameLifeLink and HappensLink are declared disjoint with Occurrence (a generalization of Object) and SelfLink specializes SelfSameLifeLink in Occurrences.kerml.

Remove disjointness of LinkObject

Agreed.

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

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

but the libraries sometimes apply it to features with values that might be intended to change over the lifetime of an instance. For example, Clause 9.2.12.2.4 (Clock) says

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

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

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

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

Remove incorrect uses of "readonly"

In the Kernel Model Libraries, the keyword "readonly" is used only in the Kernel Semantic Library, in the following places:

1. Clocks.kerml
   • readonly feature universalClock : Clock[1]
   • In Clock: readonly feature currentTime : NumericalValue[1]
   • In BasicClock: readonly feature :>> currentTime : Real
2. Links.kerml, in Link:
   • readonly feature participant: Anything[2..*] nonunique ordered;
   • readonly end feature source: Anything[0..*] subsets participant;
   • readonly end feature target: Anything[0..*] subsets participant;
3. Metaobjects.kerml
   • In Metaobject: abstract readonly feature annotatedElement : Element[1..*]
   • In SemanticMetadata: abstract readonly feature redefines annotatedElement : Type[1]
4. Observation.kerml
   • readonly feature defaultMonitor[1] : ChangeMonitor
5. SpatialFrames.kerml
   • readonly feature defaultFrame : SpatialFrame[1]
6. StatePerformances.kerml, in StatePerformance:
   • readonly feature incomingTransitionTrigger : MessageTransfer [0..1] default null
7. Transfers.kerml, in Transfer:
   • readonly feature isInstant: Boolean[1]
   • readonly feature isMove: Boolean[1] default true
   • readonly feature isPush: Boolean[1] default true

Of these, the readonly keywords should be removed from Clocks::Clock::currentTime and Clocks::BasicClock::currentTime, consistent with the original point of the issue.

In Objects.kerml, in the declaration of LinkObject:

abstract assoc struct LinkObject specializes Link, Object disjoint from SelfLink, SelfSameLifeLink, HappensLink

remove disjoint from SelfLink, SelfSameLifeLink, HappensLink.

Merge with KERML-231

This was accidentally created as a new issue, when it was intended to be the resolution to KERML-231. The proposal has now been properly added as a resolution KERML-253 for KERML-231.

"typing" seems to be non-navigable owned end of the association between Feature and FeatureTyping.
However, it is used in a constraint: deriveFeatureType - this seems a little odd.

No change

In KerML, it is allowable to have FeatureTyping relationships that are not owned by the Feature being typed, and these relationships can be added in parts of a model that are not "close" to where the typed Feature is declared. The property typing is non-navigable so that such FeatureTypings can be declared without having to update a navigable owned property of either the typed Feature or the Type typing the Feature. (On the other hand, the property ownedTyping is navigable.)

However, when computing the types of a Feature it is necessary to take into account all the FeatureTypings for that Feature whether they are owned by the Feature or not. Using typing instead of ownedTyping in deriveFeatureType handles this. Note that it is specifically allowable in OCL to "navigate" across non-navigable association ends (even though, admittedly, it is an optional conformance point for tools to navigate "non-navigable" associations – see OCL 2.4 specification, Clause 2).

2nd paragraph, last line
"end feature thatThing redefines Links::SelfLink::thatThing references f2;"
SelfLink::thatThing does not exist in ModelLibrary, 9.2.3.2.5 SelfLink, probably referring to SelfLink::sameThing

Correct connector declaration

Yes, it should be SelfLink::sameThing.

Description
3rd sentence of 1st (and only) paragraph
"This calculation may be decomposed into Expressionssteps of the Function."
The words Expressions and steps have no space between them.
There are multiple possible resolutions, such as
"into expressions of"
"into expression steps of"
"into steps of"

Correct typo

This typo is the result of an ill-formed HTML tag in the raw text. The phrase was supposed to be "Expressions that are steps".

First paragraph of the page, second sentence
"A result expression is always be written using the Expression notation described"
The phrase "expression is always be written" is grammatically incorrect.
Recommend "expression is always written"
Although I guess "expression will always be written" is grammatically correct.. I don't think it's tone is consistent with the document's tone

Correct typo

Agreed.

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

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

Revise grammar for PrimaryExpressionMember, BodyExpressionMember and FunctionReferenceExpressionMember

The issue correctly states the problem with the current grammar for PrimaryExpressionMember. Moreover, the grammar for NonFeatureChainPrimaryExpression, BodyExpressionMember and FunctionReferenceExpressionMember (the first used in FeatureChainExpression, the latter two used in FunctionOperationExpression) also have this problem. The solution in all cases is similar, as suggested for PrimaryExpressionMember in the issue description.

The semantics of an Invariant are given by its implicit specialization of one of two features in the Performances library model: either trueEvaluations or (if the Invariant is negated) falseEvaluations. These features bind the values true and false, respectively, to their result parameter. This gives the Invariant the semantics that, to be consistent, the result expression actually given in the Invariant must evaluate to true or false (respectively).

The result bindings for trueEvaluations and falseEvaluations are currently specified using ResultExpressionMemberships (to the expressions "true" and "false", respectively). However, the approved resolution to issue KERML-20 included adding the validateExpressionResultExpressionMembership constraint, which requires that an Expression has at most one ResultExpressionMembership among all its memberships, owned and inherited. In a typical Invariant of the form inv {invariantExpression}, the invariantExpression is parsed as being owned by the Invariant via a ResultExpressionMembership. But this now violates the validateExpressionResultExpressionMembership constraint, because it conflicts with the ResultExpressionMembership inherited from trueEvaluations (or falseEvaluations, if the invariant were negated).

Update the specifications of trueEvaluations and falseEvaluations

The issue can be resolved by replacing the use of ResultExpressionMemberships in trueEvaluations and falseEvaluations with explicit bindings. Note that FeatureValues cannot be used for this binding, because then it would not be possible to override them if a user wanted to use return declaration with a FeatureValue to specify the result value of an Invariant.

Constraints
checkFeatureEndSpecialization
"isEnd and owningType <> null and owningType.oclIsKindOf(Association) implies specializesFromLibrary("Links::Link::participants")"
"Links::Link::participants" does not exist, probably meant "Links::Link::participant"

Correct checkFeatureEndSpecialization constraint

Yes, it should be Links::Link::participant.

8.2.5.5 Connectors Concrete Syntax
8.3.4.5.1 Connectors Abstract Syntax - Overview
8.3.4.5.3 Connector - Attributes
The Connector Abstract Syntax and Attributes section both show a isDirected : Boolean attribute.
Neither show isDirected as a derived attribute, and there is no derivation constraint,
but there is also no textual notation to allow language users to set the attribute to true.
As far as I can tell, it will always be false, even though the description of the attribute states,
at least for binary connectors, there should be times where it could be true.

Duplicate of KERML-7

Duplicate

2nd paragraph (of page), 1st sentence
"The checkMultiplicityRangeExpressionTypeFeaturing constraint requirs that the bound Expressions of
a MultiplicityRange have the same featuringTypes as the MultiplicityRange."
There is a typo, a misspelling, of the word "requires". "constraint requirs that" should be "constraint requires that"

Correct typo

Agreed.

Last paragraph, first sentence
"If a multiplicity feature is declared in the body of a type, then then this becomes be the multiplicity of the type."
Two typos exist, 'then' is repeated, also the word 'be' is not proper English. Recommend:
"If a multiplicity feature is declared in the body of a type, then this becomes the multiplicity of the type."

Correct typos

Agreed.

Constraints
checkAssociationBinarySpecialization
"ownedEndFeature->size() = 2 implies specializesFromLibrary("Links::BinaryLink)"
Missing a quotation mark " after Links::BinaryLink

Related but possible issue?
Restricting this to ownedEndFeature instead of associationEnd can cause contradictions with inherited end features
Users could end up inheriting from an n-ary association and only redefine 2 of them?

Revise the checkAssociationBinarySpecialization constraint

It is agreed that the syntax error in the OCL needs to be fixed.

In addition, the "related but possible" issue is also a real issue. If an association specializes another association with more than two ends, but redefines only the first two (as ownedEndFeatures), then the checkAssociationBinarySpecialization constraint as currently defined would required it to specialize BinaryLink, even though it would inherit additional ends (which would then violate validateAssociationBinarySpecialization). Checking associationEnd instead of ownedEndFeature fixes this. (Note that the corresponding constraint for Connectors, validateConnectorBinarySpecialization, does not have this issue, because it already checks connectorEnd, which includes inherited ends.)

Operations
modelLevelEvaluable
2nd paragraph, first sentence
"An Expression that is not otherwise specialized is model-level evaluable if all of it has no
ownedSpecialziations and all its (non-implicit) features are..."
The word "ownedSpecialziations" is spelled wrong, it is missing an i between the l and z.
It should be "ownedSpecializiations"

Merge with KERML-248

Actually, it should be ownedSpecializations, not the suggested ownedSpecializiations. This correction is included in the resolution to issue KERML-248.

Operations
modelLevelEvaluable
I'm not convinced the OCL expression is the same as the lexical explanation directly above it.
Also the OCL may just be wrong in the 6th line
"f.ownedFeature->isEmpty() f.valuation = null and or"
This OCL needs to be very carefully looked at to align with the lexical explanation directly above it.
I didn't spend more time on this but there were other concerns I had about the Relationships check and passing visited without adding itself to the visited list.
It could be as simple as "((directionOf(f) = ... result) and f.ownedFeature->isEmpty() and f.valuation = null) or"

Correct the operation Expression::modelLevelEvaluable

The OCL for the operation is not only ill-formed, but even if that is fixed, it is incorrect: there is no such thing as an "implicit feature", and features cannot be relationships. However, it is actually not wrong that the OCL does not check or update the visited parameter. The references being tracked in this parameter are actually only those from FeatureReferenceExpressions. This should be made clearer in the operation description.

Annex A (Model Execution) has some minor errors, including:

Spelling (multiple places):

• modelled/ing => modeled/ing

• assocation => association

• multiplities => multiplicities

Cross reference missing, "Clause" => "A.3.2"

A.3.3 (One-to-one connectors)

• second bullet list, cross reference missing, "Clause" => "A.3.2"

• near end, in MyBikeWheel-Fork-BWF-Link, hypens => underscores

A.3.4 (One-to-unrestricted connectors), in second code block

• MyBasket2_BikeFork1_BBF_Link => MyBikeBasket2_Fork1_BBF_Link

• MyBikeFork1_Basket1_BBF_Link => MyBikeBasket1_Fork1_BBF_Link

• MyBikeFork1_Basket2_BBF_Link => MyBikeBasket2_Fork1_BBF_Link

A.3.5 (Timing for structures), near end, MyBike_While_Fork2End_Link => MyBikeEnd_While_Fork2End_Link

A.3.6 (Timing for behaviors, Sequences), third to last line (step redefines dry : MyShip [1]), dry => ship.

A.3.8 (Timing for behavior, Changing feature values), in the code block just after the paragraphs starting

• "Instantiation step 6.b.i. the start of 6.c.i produces", insert "redefines" as a separate word between the two "feature startShot".

• "The third of instantiation step 6.b.ii and third start of 6.c.ii produces", move "dry.dried.endShot" to just before the following semi-colon and precede it by "chains ".

• "FeatureWritePerformances ensure when they finish that", insert "in " before "redefines onOccurrence" and "redefines replacementValues (three times each).

• "The first of instantiation step 6.b.ii and first start of 6.c.ii produces", in "feature redefines onOccurrence", feature => in

Annex A, correct minor errors.

Correct Annex A as indicated.

In addition to the problems addressed in KERML-151, the deriveFeatureType constraint has the following additional problems:

1. If a Feature is conjugated, then the validateSpecializationSpecificNotConjugated constraint prohibits the Feature from being the specific Type in either FeatureTypings or Subsettings. Nevertheless, one would expect it to have the same types as the originalType that it is conjugating (assuming that is, indeed, a Feature).
2. The description of deriveFeatureType says that the resulting set of types has "all redundant supertypes removed". This should be interpreted to mean that any Type for which there is some conforming subtype should be removed from the set, not just that duplicates of the same Type are removed (as in the current OCL).

Update the deriveFeatureType constraint

The constraint deriveFeatureType needs to be updated to address both the problems identified in the issue.

"Associations with more than two association ends ("n-ary") have only target types, no source types."
related to KERML-159 and KERML-76,
On page 170
deriveAssociationSourceType and deriveAssociationTargetType contradict that with a source type always being specified as the first related type

Correct language description

The identified statement in 7.4.5 is incorrect. In addition, there is a similar statement about connectors in 7.4.6.1 ("Connectors with more than two connector ends ("n-ary") have only target features, no source features.") that also contradicts the normative constraints deriveConnectorSourceFeature and deriveConnectorTargetFeature.

There are many typos and mistakes in the grammar as written in the document
I have created separate issues for some, but there are so many I don't have time to list them all !

Also the grammar in the document and the grammar in the pilot implementation are different in many places,
also too many to list.

Close

The grammar in the pilot implementation is an implementation grammar, which is also most accommodate the limitations of the left-recursive parser technology used in that implementation. The intent is for it to be functionally equivalent to the grammar as given in the specification, but no implementation is perfect.

That said, there are admittedly errors in the grammar as given in the specification. However, these can only be corrected as they are specifically identified. Issues identifying such errors will be addressed appropriately.

The description of the validateRedefinitionDirectionConformance constraint (added by the resolution to KERML-20) is

If the redefinedFeature of a Redefinition has direction in or out, then the redefiningFeature must have the same direction. If the redefinedFeature has direction inout, then the redefiningFeature must have a non-null direction.

Consistent with this, the OCL for the constraint directly checks the direction property of the redefinedFeature. However, this does not take into account that the redefinedFeature may be inherited from a Type that is conjugated, reversing the direction of its directed Features. To account for this, the Type::directionOf operation needs to be used instead of Feature::direction.

Revise validateRedefinitionDirectionConformance constraint

Agreed.

(Note that this resolution presumes that the functionality of directionOf is corrected, as called for in KERML-154, and that directionOf will work on a redefinedFeature even though, with the Redefinition, it is no longer actually inherited.)

ConditionalExpression = 'if' ArgumentMember '?' ArgumentExpressionMember 'else' ArgumentExpressionMember ;

e.g. if x ? y else z

either use symbols or words.
Not half and half!

if x then y else z

OR

if x ? y : z

No change

This was actually thoroughly discussed by the submission team. The keyword "then" is used in the notation for succession, and so cannot be used in the conditional expression notation (this is actually more problematic in SysML, which includes various textual shorthands for succession and a "conditional succession" notation that already has the form "if...then...").

The originally proposed notation for a conditional expression was the common C notation "...?...:...". However, the feedback from modelers who were not C/Java programmers was that this was very non-intuitive. The notation "if...?..:..." was considered, but there was general agreement that it was clearer to use "else" rather than ":", even if "?" was used rather than "then".

The list of 7 relationships is inconsistent with the concrete syntax in 8.2
Specifically while all 7 of the relationships do offer feature chain syntax, the list is missing an 8th relationship
8.2.4.1.3 Conjugation
page 87
Either Conjugation should not offer featureChains in either the conjugatedType or originalType or they should be added to the list

Add conjugation to the list

Agreed, conjugation should be added to the list.

ClassifierDeclaration : ...
( SuperclassingPart | ConjugationPart )?
RelationshipPart*

RelationshipPart token does not exist in concrete syntax. Believe this is meant to be TypeRelationshipPart*

Correct production ClassifierDeclaration

It is, indeed, supposed to be TypeRelationshipPart.

Description
Last sentence in 2nd bullet
Note that his means that ..
Typo. Should be "this" means that..

Correct typo

Agreed.

checkAssociationStructureSpecialization
specializesFromLibrary("Objects::ObjectLink")
No such thing as "Objects::ObjectLink" in KerML, text references "Objects::LinkObject" which does exist

Correct OCL

Agreed.

The non-terminal <MetaClassificationTestOperator> does not exist in the specification. This is believed to be a typographical error, and the non-terminal should be <MetaclassificationOperator>.

Replace MetaclassificationOperator production

Actually, the MetaclassificationOperator production needs to be split into separate MetaClassificationTestOperator and MetaCastOperator productions.

2nd paragraph, indented, first sentance
"A project is a set of root namespaces (see 7.2.5.3 and 8.2.3.4.1), including all elements in the ownerhship
trees of those namespaces"...
ownerhship is spelled wrong, has extra h in the middle: ownership

Correct typo

Agreed.

Example Vehicle Example/VehicleDefinitions.kerml does not parse if the grammar from the document is used.

Comment is defined in the document as

Comment =
  'comment' Identification
  (  'about'  Annotation ( ',' Annotation )*  )?
 REGULAR_COMMENT

and in the implementation as

Comment returns SysML::Comment :
	( 'comment' Identification?  ('about'  Annotation  ( ',' Annotation )* )?  )?
	REGULAR_COMMENT
;

Correct the Comment production

The Comment production from the specification, as shown in the issue description, is incorrect. It should be possible to have a comment that syntactically consists simply of a REGULAR_COMMENT token (e.g., of the form "/* ... */"), without the comment keyword. The production needs to be updated to allow this (as is the case in the production from the implementation also shown in the issue description).

ConditionalBinaryOperatorExpression appears to be unused and Simple Tests/Filtering.kerml fails to parse - it contains a ConditionalBinaryOperatorExpression

I think the problem is that ConditionalBinaryOperatorExpression is missing from the definition of OwnedExpression

   OwnedExpression
        = ConditionalExpression
        | BinaryOperatorExpression
        | UnaryOperatorExpression
        | ClassificationExpression
        | MetaclassificationExpression
        | ExtentExpression
        | PrimaryExpression
    ;

Correct OwnedExpression production

Yes, ConditionalBinaryOperatorExpression is missing from the OwnedExpression production and should be included.

FeatureDeclaration ... ConjugationPart )? | FeatureSpecializationPart | FeatureConjugationPart ) ...

FeatureConjugationPart definition does not exist... probably meant just ConjugationPart

Proposed Text:

FeatureDeclaration : Feature =
( isSufficient ?= 'all' )?
( FeatureIdentification
( FeatureSpecializationPart | ConjugationPart )?
| FeatureSpecializationPart
| ConjugationPart
)
FeatureRelationshipPart*

Correct the production FeatureDeclaration

Agreed.

MetaclassificationExpression : OperatorExpression =
ownedRelationship += MetadataArgumentMember
( operator = MetaClassificationTestOperator
ownedRelationship += TypeReferenceMember
| operator = MetaCastOperator
owendRelationsip += TypeResultMember
)

The non-terminal "MetaClassificationTestOperator" does not exist. Should this be "MetaclassificationOperator" in the EBNF?

The ownedRelationship is misspelled "owendRelationsip" in the EBNF. Correct the spelling.

Duplicate of KERML-189

Duplicates KERML-189,

In the EBNF:

MetaclassificationExpression : OperatorExpression =
ownedRelationship += MetadataArgumentMember
( operator = MetaClassificationTestOperator
ownedRelationship += TypeReferenceMember
| operator = MetaCastOperator
owendRelationsip += TypeResultMember
)

There is no non-terminal named "MetaCastOperator" in the EBNF. Should this be "CastOperator" instead?

Merge with KERML-189

This is handled in the resolution to KERML-189.

In the production for FeatureDeclaration The nonterminal <FeatureConjugationPart> does not exist.

FeatureDeclaration : Feature =
( isSufficient ?= 'all' )?
( FeatureIdentification
( FeatureSpecializationPart | ConjugationPart )?
| FeatureSpecializationPart
| FeatureConjugationPart
)
FeatureRelationshipPart*

Duplicate of KERML-114

Duplicates KERML-114.

Description
1st paragraph 5th line
"originalType are considered to have an effective direction of in in the originalType."
The 2nd "originalType" is a typo and should be "conjugatedType" to be correct.

Correct typo

Agreed.

checkFeatureSubobjectSpecialization
"A composite Feature typed..."
Starting at "typed" the words are still in the Font for code
even though it should be back to the font for regular descriptive text.

Correct formatting

Agreed.

"Whether the values of this Feature can always be computed from the values of other Feature."
"Feature" at the end of the sentence should be pluralized. "... values of other Features."

Correct typo

Agreed.

Last paragraph second sentence
"Protected memberships are all owned and inherited memberships of the general type whose visibility declared as protected"

Missing part of verb phrase: whose visibility IS declared as protected

Should read:
"Protected memberships are all owned and inherited memberships of the general type whose visibility is declared as protected"

Correct typo

Agreed.

TypeDeclaration : Type =
( isSufficient ?= 'all' )? Identification
( ownedRelationship += OwnedMultiplicity )?
( SpecializationPart | ConjugationPart )+
TypeRelationshipPart*

Specifically the "( SpecializationPart | ConjugationPart )+" I don't think should be 1 or more, aka it should not have the "+" at the end.
This allows legal syntactic constructs that do have multiple ConjugationParts or ConjugationParts and SpecializationParts.
Multiple ConjugationParts or ConjugationParts and SpecializationParts appears to be against the Abstract Syntax.

A better syntax may be "( SpecializationPart+ | ConjugationPart )" if you really want to keep multiple SpecializationParts

Correct TypeDeclaration production

The intent is that a TypeDeclaration have a single one of either a SpecializationPart or a ConjugationPart. So the "+" should be removed, as suggested.

First paragraph last sentence
"Features with with no direction or direction inout in the original type are inherited without change."
Features WITH NO direction... remove second "with"

"Features with no direction or direction inout in the original type are inherited without change."

Correct typo

Agreed.

Both the Disjoining and OwnedDisjoining are missing a 'g' from the "disjoinginType = FeatureChain" parts

Disjoining =
( 'disjoining' Identification )?
'disjoint'
( typeDisjoined = [QualifiedName]
| typeDisjoined = FeatureChain
{ ownedRelatedElement += typeDisjoined }
)
'from'
( disjoiningType = [QualifiedName]
| disjoinginType = FeatureChain
{ ownedRelatedElement += disjoiningType }
)
RelationshipBody

OwnedDisjoining : Disjoining =
disjoiningType = [QualifiedName]
| disjoinginType = FeatureChain
{ ownedRelatedElement += disjoiningType }

Correct textual BNF productions

Agreed.

The signature of resolveGlobal is

resolveGlobal(qualifiedName : String) : Membership [0..1]

while uses of it sometimes apply oclAsType to the result, as in

validateRedefinitionFeaturingTypes
let anythingType: Type =
subsettingFeature.resolveGlobal('Base::Anything').oclAsType(Type) in ...

but Membership isn't a Type. Comparing to the body of specializesFromLibrary:

specializesFromLibrary(libraryTypeName : String) : Boolean
body: let mem : Membership = resolveGlobal(libraryTypeName) in
mem <> null and mem.memberElement.oclIsKindOf(Type) and
specializes(mem.memberElement.oclAsType(Type))

I gather a memberElement navigation is needed, as in

let anythingType: Type = subsettingFeature.resolveGlobal('Base::Anything').memberElement.oclAsType(Type) in

Searching on "resolveGlobal" finds quite a few missing memberElement s, eg, validateSubsettingFeaturingTypes, checkStepSpecialization, checkOperatorExpressionSpecialization, maybe others.

Correct uses of resolveGlobal

Taking into account changes from previously adopted issue resolutions, the problem identified in the issue needs to be fixed in the OCL for the following constraints:

1. validateSubsettingFeaturingTypes
2. checkOperatorExpressionSpecialization
3. checkFeatureValueBindingConnector
4. checkMetadataFeatureSemanticSpecialization

The Expression::result property in the KerML abstract syntax is suppose to subset Step::parameter, where Step is a superclass of Expression. However, in the normative KerML.xmi it is erroneously specified as subsetting Behavior::parameter, which is a different property than Step::parameter. Further, Behavior is not a direct or indirect superclass of Expression, so the subsetting is invalid in MOF/UML.

(Note that this error is not apparent in the specification document, because, in the annotation for subsetting, the subsetted parameter is shown without qualification – e.g., just parameter, not Behavior::parameter.)

Fix XMI

Agreed.

In Occurrences::InsideOf, in one of the end features

end feature smallerSpace: Occurrence[1..*] redefines source, largerSpace.spaceEnclosedOccurrences;

the second redefinition should be subsetting (it's a cross feature).

Correct InsideOf::smallerSpace

Agreed.

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

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

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

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

Correct multiplicity of Subsetting::owningFeature

Agreed that the multiplicity of Subsetting::owningFeature should be 0..1.

Note that the inverse property owningFeature of Feature::ownedRedefinition is a non-navigable owned end of the association. Therefore, it is not actually a member of Redefinition, and it is acceptable for it to have the same name as the property Subsetting::owningFeature that it subsets, which is inherited into Redefinition. (The UML rules for subsetting allow such subsettings of association ends; redefinition would not be allow.)

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

No change

The localClock feature was added to Occurrence specifically so it could be used as a default for time triggers. The localClock has to be in Occurrence, because it has to be propagated down to both contained Structures and contained Performancs. There was no such driver for spatial frames. In addition, SpatialFrame also depends on Clocks and uses localClock for defaults, while there is no such dependence of Clock on SpatialFrame.

Further, adding a feature for a "spatial reference" to Occurrence would not be consistent with the current model SpatialItem in the SysML Geometry Library, which is the primary expected application of SpatialFrames. And a SpatialItem actually is a SpatialFrame (as well as an Item). In this model, the "spatial reference" is more properly the CoordinateFrame, which is not a SpatialFrame, but, rather, a VectorMeasurementReference. And VectorMeasurementReference is defined in the Quantities and Units library, and, so, not available in KerML.

(See also KERML-282 and KERML-283 for more general statements of the issues without proposing solutions.)

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

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

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

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

And this violates the multiplicity of MetadataFeature::metaclass.

Change MetadataFeature::metaclass from a redefinition to a subset

The simplest resolution is to have MetadataFeature::metaclass subset type, rather than redefine it. In this way, a MetadataFeature will still have a single metaclass, but it may also have other Structure types that are not Metaclasses (like Item). This is acceptable, since it is essentially equivalent to have the metaclass subclassify the other types, which is already allowed.

Last Paragraph
"For example, if Car requires all instances to be four-wheeled (necessary), and then is also is indicated as sufficient, its extent will include all four wheeled things and no others."

"then is also is indicated" is not proper English.

Should probably be:
"For example, if Car requires all instances to be four-wheeled (necessary), and is also indicated as sufficient, its extent will include all four wheeled things and no others."

Example also does not do a good job of showing how the "all" on Cars enforces sufficiency. But the whole necessary/sufficient semantics is another Issue KERML-9

Correct typo

Agreed.

Forth paragraph last sentence
"A membership that would otherwise be imported is also hidden by an inherited memberships with the same member name, similarly to how it would be
hidden by a conflicting owned membership (see 7.2.5)."
Multiplicity conflict between "an" and "memberships"
There is also no need to have the word "also".

Text should read:
"A membership that would otherwise be imported is hidden by an inherited membership with the same member name, similarly to how it would be hidden by a conflicting owned membership (see 7.2.5)."

Correct text

Agreed.

Clause 9.2.3.1 (Links Overview) says

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

but the two places it appears in the Links model library

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

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

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

Link::participant generalizes association ends

Modify Clause 9.2.3.1 (Links Overview) to say Link::participant (indirectly) generalizes all association ends.

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

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

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

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

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

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

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

By default this is the singleton universalClock.

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

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

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

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

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

Model "universal" features as "individuals"

The features universalClock, defaultMonitor and defaultFrame, should have as values the singleton lives of effective "individual" occurrences of the appropriate types. That is, they should be typed by classifiers with multiplicity [1] that specialize both Life and each of Clock, Monitor and SpatialFrame. The features thus represent the lives of these individual over all time, while still allowing for the separate modeling of time slices and snapshots that are typed by the general classifiers, but portions of the specific individual lives.

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

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

but

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

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

Add SpaceLink, disjoint from Occurrence

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

Add association Occurrences::SpaceLink disjoint from Occurrence (corresponding to InsideOf and OutsideOf (corresponding to HappensLink generalizing HappenDuring and HappenBefore). This will make spatial links disjoint from LinkObject also, see KERML-231.

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

This is reported in KERML-46

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

binding picture = focus.picture;

I assume this should be

binding picture = shoot.picture;

in order to be consistent with the declaration before.

Correct example

Correct as proposed.

The second line of the following does not parse:

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

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

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

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

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

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

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

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

Correct textual notation for Connectors

It would clearly be desirable to include ValuePart in the connector notation. However, introducing ValuePart into the NaryConnectorDeclartion notation after FeatureDeclaration causes an ambiguity in the grammar with an InvocationExpression in the ValuePart. For example, it would not longer be possible to syntactically distinguish whether connector c = f(a,b); is to be parsed as an connector bound to the InvocationExpression f(a,b), or as an n-ary connector bound to the FeatureReferenceExpression f and having related features a and b.

While it would be possible to allow a ValuePart in the binary connector notation, it seems more consistent to allow it only when not using either of the special binary or n-ary connector notations. Note that this is only a notational limitation, not a functional one, since end members can always be specified in the connector body. And it also seems likely that a feature value will be used with a connector mostly when no related features are specified, anyway.

Clause 9.2.5.1 (Objects Overview) says

Objects and Performances do not overlap

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

Clause 7.4.4 (Structures) says

Structures and behaviors do not overlap,

but there is no constraint for this.

Make Object and Performance disjoint

Objects::Object and Performances::Performance can be made disjoint. There is currently no metaclass in the abstract syntax that is both a Structure and a Behavior. However, there is currently nothing to prevent a Structure from specializing a Behavior, or vice versa, which would violate the disjointness of Object and Performance. There needs to be a constraint to prevent this (similar to the validateClassSpecialization constraint that prevents Classes from specializing DataTypes or Associations).

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

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

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

Regenerate the KerML.kerml model file

The KerML.kerml file is generated from the normative KerML abstract syntax. The reported errors were due to the file not being properly regenerated subsequent to some final abstract syntax updates before submission. The file should now be regenerated, not only to correct the reported errors, but also to reflect all other abstract syntax changes approved by the FTF.

Features
self : Anything

The subsetting is inconsistent with Base.kerml which has "feature self: Anything[1] subsets things chains things.that"

Update documentation

Agreed.

In standard library Occurrences.kerml the declaration for abstract class Occurrence still uses deprecated documentation preceding the declaration. It should be moved to a doc annotation inside the curly brackets.

Correct documentation

Agreed.

The approved resolution to issue KERML-20 added the validationRedefinitionDirectionConformance constraint. However, the Occurrences and TransitionPerformances models in the Kernel Model Library actually violate that constraint. They need to be updated so they do not.

1. Occurrences::ObserveChange::transfer::source::sourceOutput should have direction out.
2. TransitionPerformances::TransitionPerformance::accept should have direction in.

Update the library models as necessary

The Observation and TransitionPerformances models need to be updated as given.

The Kernel Standard Library model for Transfers includes the following features, documented in subclauses of 9.2.7.2:

• 9.2.7.2.4 flowTransfers
• 9.2.7.2.5 flowTransfersBefore
• 9.2.7.2.7 messageTransfers
• 9.2.7.2.11 transfers
• 9.2.7.2.12 transfersBefore

In all these cases, the "Element" kind is documented simply as "Feature". However, in the normative Transfers.kerml file, all of these features are actually declared as steps.

Update library model specification

Actually, it makes even more sense for these features to be item flows, since they are all typed by Transfer or a specialization of it. And, if these item flows are declared as abstract, then it is not necessary to actually provide the related features for the connector ends of the item flow.

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

8.3.3.1.10 Type

validateTypeOwnedUnioningNotOne – A Type must not have exactly one ownedUnioning.

validateTypeOwnedIntersectingNotOne – A Type must not have exactly one ownedIntersecting.

validateTypeOwnedDifferencingNotOne – A Type must not have exactly one ownedDifferencing.

8.3.3.3.3 Feature

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

8.3.3.3.8 Redefinition

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

8.3.3.3.10 Subsetting

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

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

8.3.4.5.2 BindingConnector

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

8.3.4.5.3 Connector

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

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

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

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

8.3.4.8.3 FeatureChainExpression

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

8.3.4.8.4 FeatureReferenceExpression

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

8.3.4.8.5 InvocationExpression

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

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

8.3.4.8.14 OperatorExpression

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

8.3.4.8.15 SelectExpression

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

8.3.4.10.2 FeatureValue

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

8.3.4.12.3 MetadataFeature

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

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

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

Add missing constraints

Most of the new constraints proposed in the issue description are added to the abstract syntax. However, the following are not included, or are different from what was suggested, for the reasons given below.

1. validateRedefinitionFeatureConformance – Allows an inout direction to be redefined as in or out as well as inout.
2. validateSubsettingMultiplicityConformance – Not included. This will be considered separately with other issues related to multiplicity semantics.
3. validateBindingConnectorTypeConformance – Not included. For semantic reasons, this and other type-checking constraints will be considered separately (see also the discussion on KERML-127).
4. validateConnectorAssociationEnds – Not included. This constraint was intended to formalize a statement made in subclause 7.4.6.2 of the Language Description. However, enforcing this would prevent an n-ary connector from declaring ends, since the base connector Links::Link has no ends. Instead, the relevant paragraph in 7.4.6.2 is rewritten.
5. validateConnectorTypeFeaturing – Not included. This constraint was intended to provide a validation check of checkConnectorTypeFeaturing in case it is not possible to add an implied relationship to satisfy that constraint. However, it is sufficient for a tool to just report that checkConnectorTypeFeaturing cannot be satisfied in this case.
6. validateExpressionResultExpressionMembership and validateFunctionResultExpressionMembership – Check all memberships (owned or inherited), not just ownedMemberships. Checking for just owned ResultExpressionMemberships would still allow a Function or Expression to inherit multiple result expressions from multiple supertypes, which would not have any clear meaning.
7. validateOperatorExpressionCastConformance – Not included. This is essentially another type-checking constraint, which will be handled separately.

7.4.1 (Kernel Overview) says

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

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

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

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

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

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

Make Occurrence::Occurrence disjoint from Base::DataValue

Occurrence::Occurrence should be declared as disjoint from Base::DataValue.

The approved resolution to issue KERML-20 added the validateFeatureValueOverriding constraint, which requires "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues".

1. The Transfers model in the Kernel Semantic library binds certain features that are intended to be overridden in user models, but such overriding now causes violations of the validateFeatureValueOverriding constraint:
   • Transfers::Transfer::isInstant
   • Transfers::SendPerformance::sentItem
   • Transfers::AcceptPerformance::acceptedItem
2. In the ComplexFunctions model in the Kernel Function Library, the functions sum and product bind their result parameters. However, these results are overridden in the corresponding functions in RealFunctions, RationalFunctions and IntegerFunctions models, which violates the validateFeatureValueOverriding constraint. Similarly, the result of the VectorFunctions::vectorScalarMult function is overridden in its specialization cartesianScalarVectorMult, which also violates the constraint. Using a default feature value instead of binding would eliminate all these violations.

Update the library models as necessary

The library models identified in the issue are updated as given. Note that these updates preserve the intended use of all the models in question.

The Min and Max functions have uppercase-initial names in DataFunctions. However, all the specializations of these functions in ScalarFunctions, NumericalFunctions, etc. have lowercase-initial names min and max. The names in DataFunctions should be the same.

Make the names lowercase

Agreed that the names should be lowercase-initial.

In the Kernel Semantic Library Transfers model, the Transfer::source::sourceOutput feature has direction out and the Transfer::target::targetInput feature has direction in. In the ItemFlowEnds of an ItemFlow, these features are redefined, with the redefined Features being corresponding Features of the source and target Features of the ItemFlow. However, the validateRedefinitionDirectionConformance constraint added by the resolution to KERML-20 means that these ItemFlowEnd Features must also have directions out and in, respectively (or inout) – that is, that a flow must be from an output Feature to an input Feature. While this may make sense for the typical connection of the output parameter of one Step to the input parameter of another, it disallows the ability to flow e.g., from an input parameter of a Behavior to an input of one of its steps or from an output parameter of a step to an output of the containing Behavior.

Remove directions from sourceOutput and targetInput

The directions can simply be removed from the sourceOutput and targetInput Features. However, this will still result in a violation of validateRedefinitionDirectionConformance if one or both of these Features are then redefined in an ItemFlowEnd with a redefinedFeature that has any direction at all. The simplest way to avoid this further problem is to note in the textual notation grammar that such ItemFlowEnd Features must be given the direction of their redefinedFeatures.

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

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

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

Revise IfThenElsePerformance

The easiest solution is to have IfThenElsePerformance specialize IfThenPerformance, adding the additional elseClause parameter and the specification for the "else" behavior as in IfElsePerformance. The specification of IfElsePerformance can remain unchanged (IfElsePerformance is used in the specification of LoopPerformance).