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.

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 SysML spec,
ControlPerformances::DecisionPerformance::outgoingHBLink:: earlierOccurrence is not marked as "end" feature.

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.

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.

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.

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.

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

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

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

but this semantics is not model/mathed.

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

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

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

but this semantics is not model/mathed.

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

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

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.

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.

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.

The execution algorithm in Annex A should could more cases.

The execution algorithm in Annex A should could more cases.

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.

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.

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.

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

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

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?

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.

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.

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.

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

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

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.

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.

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.

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

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

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

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

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

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

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

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

The OCL for the validateTypeAtMostOneConjugator constraint references the Conjugator relationship, which does not exist. This should instead be Conjugation.

Also, the constraint has no documentation.

Description
2nd Sentence
"If isRecursive = false, then only the visible Memberships of the importOwningNamespace are imported."

The issue is that importedNamespace Memberships are imported, not importOwningNamespace Memberships as written;

So it should read:

"If isRecursive = false, then only the visible Memberships of the importedNamespace are imported."

Constraints section
2nd sentence:
"The specific Type of a Generalization cannot be a conjugated Type."
1st issue, typo: Replace Generalization with Specialization

2nd issue, serious: This prevents Conjugated Types from specializing the Conjugated Types of their originalTypes more general Types.

We probably should allow Specialization between Conjugated Types if their originalTypes have the a Specialization relationship (in the same direction). Or maybe it's implied?

Description
2nd Sentence
"The ownedMemberElementM becomes an ownedMember of the membershipOwningNamespace."

ownedMemberElementM does not exist, has an extra "M" at the end, should read:

"The ownedMemberElement becomes an ownedMember of the membershipOwningNamespace."

Constraints
deriveFeatureOwnedSubsetting
"The ownedRedefinitions of a Feature are its ownedSpecializations that are Subsettings."
Text should not be referring to the ownedRedefinitions, but to the ownedSubsetting

Proposed text:
"The ownedSubsettings of a Feature are its ownedSpecializations that are Subsettings."

Constraints
deriveElementIsLibraryElement
"isLibraryElement = libraryNamespace() <>null"
There needs to be a space between the operator and the null.

Should read:
"isLibraryElement = libraryNamespace() <> null"

Description
"A FeatureMembership is ... that is also a Featuring RelationshipFeature and the Type, ..."

"RelationshipFeature" is not a LexicalToken.. this is a typo in the sentence.

It probably should read:
"that is also a Featuring relationship between the Feature and the Type," ...

Namespace
Description
A Namespace is an Element that contains other Element, known as its members...
There is a missing plurality on the second "Element" in the first sentence.

"via Import Relationships with other Namespace."
Probably need to at least pluralize Namespace since Relationships is plural, and maybe change "with other" to something else like "with target", or delete "with other Namespace", since it's not critical info as the Import relationship is not just "with" a Namespace, it is either with a Namespace or Membership.

As well as a typo in the second sentence of the 2nd paragraph.
"If a Membership specifies a memberName and/or memberShortName, then that
those are names of the corresponding memberElement relative to the Namespace."
Remove "that" from between "then" and "those"

The documentation for the constraint validateSpecializationSpecificNotConjugated is "The specific Type of a Generalization cannot be a conjugated Type." Generalization should be changed to Specialization.

Constraint Text:
The memberElementId of a Membership is the elementIf of its memberElement
Should be "elementId", not "elementIf"

Constraint
deriveFeatureFeaturingType
Feature.featuringType is shown as the union of all the typeFeaturings that feature it with the first type of a feature chain. But what is not included is the possible FeatureMembership.
This conflicts with the fact that Feature.owningType subsets featuringType and Feature.owningType is the owningType of an owningFeatureMembership. (Bonus: there is no derived property for codifying that statement of the derived /owningType attribute).

Resolution of this issue may be worth utilizing typeWithFeature in more places instead of featuringType

Constraints
deriveTypeFeatureMembership
featureMembership = ownedMembership->union(inheritedMembership->selectByKind(FeatureMembership))
The unioning metaproperty should not be ownedMembership, that is too broad and conflicts text the unioning metaproperty should be ownedFeatureMembership

Proposed text:
featureMembership = ownedFeatureMembership->union(inheritedMembership->selectByKind(FeatureMembership))

The documentation for the constraint validateClassSpecializtion states:

A Class must not specialize a DataType and it can only specialize an Association if it is an AssociationStructure.

with the OCL

ownedSpecialization.general->
    forAll(not oclIsKindOf(DataType)) and
not oclIsKindOf(AssociationStructure) implies
    ownedSpecialization.general->
        forAll(not oclIsKindOf(Association))

However, an Interaction is both a Behavior, which is a kind of Class, and an Association, and, for example, the library interaction Transfer specializes both Performance (a behavior) and BinaryLink (an association). But the above constraint disallows this specialization.

The validateClassSpecialization constraint needs to be updated to allow both AssociationStructures and Interactions to specialize Associations.

The deriveFeatureType constraint recursively accesses the types of the subsetted Features of a Feature. However, it does not take into account that subsetting relationships may be circular.

Also, the description of the constraint states "If a Feature has chainingFeatures, then its types are the same as the last chainingFeature." However, the OCL actually unions the types of the last chainingFeature with the others.

Constraints
deriveTypeOwnedDifferencing, deriveTypeOwnedDisjoining, deriveTypeOwnedUnioning
All 3 OCL derivation expressions are missing the attribute assignment "=" like all the other derive Constraints

Description
3rd sentence
"Since FeatureTyping is a kind of Generalization, this means that Anything is also a generalization of things."
FeatureTyping is a kind of Specialization, not Generalization. Recommend: "this means that Anything is the general Type of things."

GeneralTypes
"DataValue
Integer"
Since Integer is an, indirect, specialization of DataValue, there does not need to be an explicit direct specialization.
Probably a typo, as most other ScalarValues only have their immediate more general type listed.

3rd sentence of paragraph
"They are specialized into most general DataType DataValue, the type of dataValues,
the most general Feature typed by DataTypes, respectively (see 8.3.4.1)."
This sentence is missing a "the" between "into" and "most"

1st paragraph, last sentence
"For example, the time and space taken by a room might have air moving in it it, as
well as light, radio waves, and so on."
Typo. The word "it" is repeated in succession, recommend removing one of them.

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.

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.

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.

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.

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.

Features
self : Anything

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

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.

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

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

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

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.

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

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"

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 }

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

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*

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.

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.

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.

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

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?

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

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

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
;

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
    ;

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

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

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

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

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

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

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

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

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

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.

"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

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

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.

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.

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"

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"

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

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"

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?

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"

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

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

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

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"

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

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.

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.

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.

[Filed for Mr. Raphael Barbau] Clause 9.2.4.1 (Occurrences Overview), under Portions, first paragraph, the last sentence says

They must be classified the same way as the Occurrences they are portionsOf, or more specialized.

For a behavior with mandatory steps (features with lower multiplicity>1 typed by behaviors), this means every portion of its performances, including every snapshot, would need to have values for these steps, even when the steps are not intended to happen during/inside of that portion. Likewise for a structure with mandatory parts, eg, like an engine in a car, all spaceslices would need to have this part. The semantic above is not math/modeled.

Comment indicates that this should be Subclassification

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.

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.

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.

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.

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

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

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

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

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

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