Kernel Modeling Language Avatar
  1. OMG Specification

Kernel Modeling Language — Open Issues

  • Acronym: KerML
  • Issues Count: 68
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
KERML11-82 Error in constraint checkFeatureFlowFeatureRedefinition KerML 1.0b4 open
KERML11-81 Abstract syntax XMI contains spurious associations KerML 1.0b4 open
KERML11-77 The term "connector end multiplicities" not updated to "connector cross multiplicities" KerML 1.0b4 open
KERML11-76 Library models have inherited member name collisions KerML 1.0b2 open
KERML11-18 isAbstract, semantics KerML 1.0a1 open
KERML11-79 TransitionPerformance::accept is incorrect KerML 1.0b4 open
KERML11-78 Transfers::transfers and Transfers::flowTransfers subset each other KerML 1.0b4 open
KERML11-75 OCL for importedMemberships is incorrect KerML 1.0b4 open
KERML11-74 Typo in OCL constraint KerML 1.0b2 open
KERML11-73 State::entryAction HappensJustBefore State::doAction KerML 1.0b2 open
KERML11-72 Redefinition inheritance anomaly KerML 1.0b2 open
KERML11-71 TriggerAfter uses a binding to var 'currentTime' KerML 1.0b2 open
KERML11-30 Feature values do not specify when their expressions are evaluated KerML 1.0a1 open
KERML11-70 FeatureChainExpression semantic constraint OCL is wrong KerML 1.0b2 open
KERML11-69 Indexing Collection types KerML 1.0b2 open
KERML11-5 Description and semantics of model-level evaluable constructor expressions KerML 1.0b2 open
KERML11-42 TimeOf::timeContinuityConstraint might be too restrictive KerML 1.0a1 open
KERML11-40 Annex A coverage KerML 1.0b1 open
KERML11-52 Incorrect succession in state and transition library KerML 1.0b2 open
KERML11-44 isDerived, semantics KerML 1.0b1 open
KERML11-68 End feature cannot be used in a feature chain expression KerML 1.0b2 open
KERML11-45 Discrepancy between documentation of Collections library in spec and textual notation file KerML 1.0a1 open
SYSML21-274 ShapeItems can't be SpatialItems KerML 1.0b2 open
SYSML21-245 Message Connector Ends are Absent by Default; If Ends are Specified, Message is Indistinguishable from Flow KerML 1.0b2 open
KERML11-48 TransferBefore is unsatisfiable KerML 1.0b2 open
KERML11-50 Eliminate EndFeatureMembership and ParameterMembership from abstract syntax KerML 1.0b2 open
KERML11-49 HappensLink disjointness documentation inconsistent KerML 1.0b2 open
KERML11-51 Problem with nested feature semantics KerML 1.0b2 open
KERML11-46 Space triggers missings KerML 1.0b1 open
KERML11-47 Impossible to specialize (redefine, subset) unnamed features in textual syntax KerML 1.0b2 open
KERML11-41 Some syntax in Core has time-dependent semantics KerML 1.0a1 open
KERML11-39 Serious limitation of textual concrete syntax as model interchange format KerML 1.0b1 open
KERML11-37 Ambiguity In Directionality InOut semantics KerML 1.0b1 open
KERML11-38 Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature KerML 1.0b1 open
KERML11-36 Root namespaces restricted to one single file KerML 1.0b1 open
KERML11-35 Add validateSubsettingTypeConformance constraint KerML 1.0b1 open
KERML11-34 Inherited multiplicities, semantics KerML 1.0b1 open
KERML11-32 Default for the first operand of a classification expression KerML 1.0a1 open
KERML11-33 validateAssociationStructureIntersection seems vacuous KerML 1.0b1 open
KERML11-29 Some package-level features are mandatory KerML 1.0a1 open
KERML11-31 Invariants only hold when evaluated KerML 1.0a1 open
KERML11-25 Conditions missing for some sufficient library types KerML 1.0a1 open
KERML11-28 Machine readable project interchange file(s) for language description examples KerML 1.0a1 open
KERML11-26 XMI and JSON for model libraries KerML 1.0a1 open
KERML11-27 Some types not given any semantics KerML 1.0a1 open
KERML11-24 Sufficiency missing for some library types KerML 1.0a1 open
KERML11-22 Decision/MergePerformance element descriptions give incorrect modeling pattern KerML 1.0a1 open
KERML11-23 Succession end multiplicity defaults not documented KerML 1.0a1 open
KERML11-21 Steps are not always time enclosed KerML 1.0a1 open
KERML11-20 direction, semantics KerML 1.0a1 open
KERML11-19 isSufficient, semantics, expressiveness KerML 1.0a1 open
KERML11-14 Classifier multiplicity, semantics KerML 1.0a1 open
KERML11-17 isPortion, semantics KerML 1.0a1 open
KERML11-15 Dynamic multiplicity, semantics KerML 1.0a1 open
KERML11-16 isReadOnly, semantics KerML 1.0a1 open
SYSML21-7 Missing descriptions of specialized effective naming KerML 1.0b2 open
KERML11-13 Editorial mistake in explanation of composite or portion feature KerML 1.0b2 open
KERML11-8 checkConnectorTypeFeaturing fails on implied BindingConnector of a FeatureReferenceExpression KerML 1.0b2 open
KERML11-9 Typo in documentation of Transfer::isInstant KerML 1.0b2 open
KERML11-12 Filtering is not applied on imported packages KerML 1.0b2 open
KERML11-11 isCompatibleWith operation needs a return type KerML 1.0b2 open
KERML11-10 keywords 'standard' and 'library' are missing in list of keywords KerML 1.0b2 open
KERML11-4 Error in constraint checkMultiplicityTypeFeaturing KerML 1.0b2 open
KERML11-6 Error in constraint checkFeatureParameterRedefinition KerML 1.0b2 open
KERML11-3 Featuring type of the multiplicity of a cross feature KerML 1.0b2 open
KERML11-2 Occurrences::surroundedByOccurrences::surroundingSpace should not be an end feature KerML 1.0b2 open
KERML11-7 Error in constraint deriveFeatureFeaturingType KerML 1.0b2 open
KERML11-1 Binding connectors should not be considered owned cross features KerML 1.0b2 open

Issues Descriptions

Error in constraint checkFeatureFlowFeatureRedefinition

  • Key: KERML11-82
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b4 — Fri, 29 Aug 2025 22:57 GMT
  • Updated: Fri, 29 Aug 2025 22:57 GMT

Abstract syntax XMI contains spurious associations

  • Key: KERML11-81
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b4 — Fri, 29 Aug 2025 21:15 GMT
  • Updated: Fri, 29 Aug 2025 21:15 GMT

The term "connector end multiplicities" not updated to "connector cross multiplicities"

  • Key: KERML11-77
  • Status: open  
  • Source: gmail.com ( Prof. Gerd Wagner)
  • Summary:

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

    • 9.2.9.1, p. 336
    • A.3.3, p. 409 + 410
    • A.3.7, p. 417
  • Reported: KerML 1.0b4 — Mon, 28 Jul 2025 18:32 GMT
  • Updated: Fri, 29 Aug 2025 21:09 GMT

Library models have inherited member name collisions

  • Key: KERML11-76
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Kernel Semantic Library

    • FeatureReferencingPerformances
    • Objects
    • Observation

    Kernel Function Library

    • VectorFunctions
  • Reported: KerML 1.0b2 — Thu, 24 Jul 2025 23:11 GMT
  • Updated: Fri, 29 Aug 2025 21:00 GMT


TransitionPerformance::accept is incorrect

  • Key: KERML11-79
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

Transfers::transfers and Transfers::flowTransfers subset each other

  • Key: KERML11-78
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b4 — Thu, 31 Jul 2025 18:27 GMT
  • Updated: Thu, 31 Jul 2025 18:27 GMT

OCL for importedMemberships is incorrect

  • Key: KERML11-75
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0b4 — Thu, 24 Jul 2025 22:59 GMT
  • Updated: Thu, 24 Jul 2025 22:59 GMT

Typo in OCL constraint

  • Key: KERML11-74
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    There is a typo in checkFeatureObjectSpecialization:

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

    The word "Libary" misses a "r".

  • Reported: KerML 1.0b2 — Thu, 17 Jul 2025 12:17 GMT
  • Updated: Thu, 24 Jul 2025 22:54 GMT

State::entryAction HappensJustBefore State::doAction

  • Key: KERML11-73
  • Status: open  
  • Source: Ansys Government Initiatives ( Mr. Richard Page)
  • Summary:

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

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

    (Emphasis Added)

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

  • Reported: KerML 1.0b2 — Thu, 17 Jul 2025 21:41 GMT
  • Updated: Thu, 17 Jul 2025 21:41 GMT

Redefinition inheritance anomaly

  • Key: KERML11-72
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

    But consider applying this rule to the following model:

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

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

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

  • Reported: KerML 1.0b2 — Tue, 8 Jul 2025 22:14 GMT
  • Updated: Wed, 9 Jul 2025 02:55 GMT

TriggerAfter uses a binding to var 'currentTime'

  • Key: KERML11-71
  • Status: open  
  • Source: Ansys Government Initiatives ( Mr. Richard Page)
  • Summary:

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

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

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

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

    private feature referenceTime : NumericalValue := clock.currentTime;
    
    return signal : TimeSignal [1] = TriggerAt(referenceTime + delay, receiver, clock, monitor);
    
  • Reported: KerML 1.0b2 — Thu, 3 Jul 2025 22:31 GMT
  • Updated: Tue, 8 Jul 2025 21:30 GMT

Feature values do not specify when their expressions are evaluated

  • Key: KERML11-30
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.3.4.10.2 (FeatureValue) and 8.4.4.11 (Feature Values Semantics) say

    A FeatureValue is a Membership that identifies a particular member Expression that provides the value of the Feature that owns the FeatureValue.

    A FeatureValue is a kind of OwningMembership between a Feature and an Expression.

    but does not require the model to specify when the expression is evaluated. Expressions (as steps) owned by some features are required to happen (be evaluated) during instances of the featuring types (domain) of that feature (see KERML-11), which might be too loose for some applications, while those owned other features are unconstrained, for example, their values could be the results of an expression evaluated before or after the instance of domain types exists. The results could vary over time if the expression reads values of other features. This seems to apply to all the combinations of default/initial feature values.

  • Reported: KerML 1.0a1 — Mon, 1 May 2023 19:47 GMT
  • Updated: Thu, 3 Jul 2025 22:38 GMT

FeatureChainExpression semantic constraint OCL is wrong

  • Key: KERML11-70
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 3 Jul 2025 19:34 GMT
  • Updated: Thu, 3 Jul 2025 19:34 GMT

Indexing Collection types

  • Key: KERML11-69
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint checkIndexExpressionResultSpecialization requires that

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

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

  • Reported: KerML 1.0b2 — Sun, 29 Jun 2025 20:34 GMT
  • Updated: Sun, 29 Jun 2025 22:13 GMT

Description and semantics of model-level evaluable constructor expressions

  • Key: KERML11-5
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 19 Jun 2025 16:43 GMT
  • Updated: Wed, 25 Jun 2025 21:27 GMT

TimeOf::timeContinuityConstraint might be too restrictive

  • Key: KERML11-42
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

    In Clocks.kerml, the TimeOf function defines the timeContinuityConstraint, which states that (endShots of) immediate predecessors of an occurrence (i.e., those connected via a HappensJustBefore) must get the same timestamp (timeInstant in the model) as the start shot of the occurrence:

    inv timeContinuityConstraint {
    	doc
    	/*
    	 * If one Occurrence happens immediately before another, then the TimeOf 
    	 * the end snapshot of the first Occurrence equals the TimeOf the second
    	 * Occurrence.
    	 */
    	
    	o.immediatePredecessors->forAll{in p : Occurrence; 
    		TimeOf(p.endShot, clock) == timeInstant
    	}
    }	
    

    Compare this to the documentation of HappensJustBefore, which states that "HappensJustBefore is HappensBefore asserting that there is no possibility of another occurrences[sic] happening in the time between the earlierOccurrence and laterOccurrence."

    Considering that the intent of the libraries is not to constrain the time model and the format of timestamps, I checked this against three widely-used time models.

    With continuous (dense) time, the current formulation of the timeContinuityConstraint might make sense, although it fails to capture that an infinite number of snapshots forming a HappensJustBefore chain may actually take non-zero time.

    With discrete time, where a timestamp may be treated as a sequence number, for example, an Integer, the invariant may be too restrictive, as HappensJustBefore could apply to two snapshots that have successive sequence numbers, but have no other occurrence in between them. In fact, in a discrete time model, HappensJustBefore with the current definition degrades to HappensWhile because there is no notion of ordering between events with the same timestamp.

    In super-dense time, where a clock is usually represented as a pair of a real value (timestamp) and an integer (sequence number to order events with the same timestamp), the invariant is again not very well defined because a pair with the same timestamp and smaller sequence number is generally considered to be (strictly) "less than".

    Overall, I think the difference between HappensBefore and HappensJustBefore cannot be captured in the TimeOf function, but should rather be enforced on the succession graph induced by these relations as specified in the documentation of HappensJustBefore (but not formalized, as far as I am aware), independent of the timestamps. This would imply that the invariant should be removed from the library.

    Alternatively, if the intent was to say there is no other possible value between the timestamp of the occurrence and that of its immediate predecessors (which degrades to the current definition with continuous time), the constraint could capture this better by asserting that there is no otherTimeInstant such that otherTimeInstant < timeInstant and TimeOf(p.endShot, clock) < otherTimeInstant. This would allow discrete clocks to assign successive timestamps to occurrences in a HappensJustBefore relation, forbid continuous clocks to assign different timestamps (as there is always another real number between any two), and force pairs in super-dense time to assign pairs with the same timestamp and either the same or successive sequence numbers.

  • Reported: KerML 1.0a1 — Sat, 25 Nov 2023 11:20 GMT
  • Updated: Wed, 25 Jun 2025 21:15 GMT

Annex A coverage

  • Key: KERML11-40
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The execution algorithm in Annex A should could more cases.

  • Reported: KerML 1.0b1 — Wed, 1 Nov 2023 20:08 GMT
  • Updated: Wed, 25 Jun 2025 21:15 GMT

Incorrect succession in state and transition library

  • Key: KERML11-52
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

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

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

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

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

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

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

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

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

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

  • Reported: KerML 1.0b2 — Fri, 10 Jan 2025 15:46 GMT
  • Updated: Wed, 25 Jun 2025 21:14 GMT
  • Attachments:

isDerived, semantics

  • Key: KERML11-44
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: KerML 1.0b1 — Thu, 14 Dec 2023 15:32 GMT
  • Updated: Tue, 24 Jun 2025 17:56 GMT

End feature cannot be used in a feature chain expression

  • Key: KERML11-68
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Given the above, a FeatureChainExpression of the form

    src.f
    

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

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

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

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

  • Reported: KerML 1.0b2 — Sun, 22 Jun 2025 22:41 GMT
  • Updated: Sun, 22 Jun 2025 22:41 GMT

Discrepancy between documentation of Collections library in spec and textual notation file

  • Key: KERML11-45
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    The doc annotations of the datatypes in standard library Collections.kerml in machine readable document ad/23-02-05 are not aligned with the contents of subclause 9.3.3 of the KerML specification.

    The documentation content should be made identical. The text in the KerML specification should be leading when drafting a resolution for this issue.

  • Reported: KerML 1.0a1 — Wed, 20 Dec 2023 09:37 GMT
  • Updated: Sat, 21 Jun 2025 19:03 GMT

ShapeItems can't be SpatialItems

  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b2 — Sat, 25 Jan 2025 16:54 GMT
  • Updated: Fri, 20 Jun 2025 22:41 GMT

Message Connector Ends are Absent by Default; If Ends are Specified, Message is Indistinguishable from Flow

  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

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

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

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

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

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

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

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

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

    To summarise:

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

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

  • Reported: KerML 1.0b2 — Mon, 25 Nov 2024 16:23 GMT
  • Updated: Fri, 20 Jun 2025 22:41 GMT

TransferBefore is unsatisfiable

  • Key: KERML11-48
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

    assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...
    

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

  • Reported: KerML 1.0b2 — Thu, 25 Jul 2024 20:18 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Eliminate EndFeatureMembership and ParameterMembership from abstract syntax

  • Key: KERML11-50
  • Status: open  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

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

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

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

    Proposal:
    Eliminate EndFeatureMembership and ParameterMembership from the abstract syntax.

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

  • Reported: KerML 1.0b2 — Tue, 30 Jul 2024 12:52 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

HappensLink disjointness documentation inconsistent

  • Key: KERML11-49
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

    assoc HappensLink specializes BinaryLink disjoint from Occurrence { ...
    

    aligning with the disjointness justifications above.

  • Reported: KerML 1.0b2 — Mon, 29 Jul 2024 19:22 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Problem with nested feature semantics

  • Key: KERML11-51
  • Status: open  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

    Consider the following example:

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

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

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

    Some questions that highlight the meaning of this interpretation:

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

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

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

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

    In this case, the extents would look like this:

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

    Answers to the above questions change:

    • Who is Joe's employer (i.e., what is the value of joe.employer)?
      • It is joesEmployer.
    • Do Jane and Joe work at the same company (i.e., jane.employer == joe.employer)?
      • *No, the values of these features are different (janesCorp vs. joesCorp).
    • Do Jane and Joe earn the same at bestCorp (i.e., jane.employer.salary == joe.employer.salary)?
      • No, the values of the feature "salary" for janesCorp and joesCorp are not the same, although we do not know that they work at bestCorp (see previous answer).
    • What car does Joe drive (i.e., what is the value of joe.drivenCars)?
      • He drives joesCar.
    • Do Jane and Joe drive the same car (i.e., jane.drivenCars == joe.drivenCars)?
      • No, the values of these features are different (janesCar vs. joesCar).
    • Who are the drivers of Joe's car (i.e., what is the value of joe.drivenCars.drivers)?
      • They are only Joe because his car is joesCar and that is associated only with Joe.
    • Who are the drivers of Jane's car (i.e., what is the value of jane.drivenCars.drivers)?
      • They are only Jane because his car is joesCar and that is associated only with Jane.
    • Who are the drivers of fastCar (i.e., fastCar.drivers)?
      • Nobody, because there is no sequence beginning with fastCar.
  • Reported: KerML 1.0b2 — Mon, 9 Sep 2024 16:21 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Space triggers missings

  • Key: KERML11-46
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: KerML 1.0b1 — Thu, 21 Dec 2023 17:05 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Impossible to specialize (redefine, subset) unnamed features in textual syntax

  • Key: KERML11-47
  • Status: open   Implementation work Blocked
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

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

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

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

  • Reported: KerML 1.0b2 — Mon, 27 May 2024 03:01 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Some syntax in Core has time-dependent semantics

  • Key: KERML11-41
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Some (abstract and textual) syntax in Core has (informal) semantics requiring time, such as Feature::isComposite, ::isReadOnly, ::isPortion, as well as ::direction and ::isDerived, see 7.3.4.2 (Feature Declaration) and 8.3.3.3.3 (Feature), but Core does not include a time model.

  • Reported: KerML 1.0a1 — Thu, 9 Nov 2023 14:13 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Serious limitation of textual concrete syntax as model interchange format

  • Key: KERML11-39
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

    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.
  • Reported: KerML 1.0b1 — Sat, 28 Oct 2023 14:22 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Ambiguity In Directionality InOut semantics

  • Key: KERML11-37
  • Status: open  
  • Source: Self ( Jim Ciarcia)
  • Summary:

    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?

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 17:58 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature

  • Key: KERML11-38
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    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.

  • Reported: KerML 1.0b1 — Tue, 17 Oct 2023 19:02 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Root namespaces restricted to one single file

  • Key: KERML11-36
  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    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
    
  • Reported: KerML 1.0b1 — Mon, 11 Sep 2023 17:55 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT
  • Attachments:

Add validateSubsettingTypeConformance constraint

  • Key: KERML11-35
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    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.

  • Reported: KerML 1.0b1 — Tue, 1 Aug 2023 15:32 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Inherited multiplicities, semantics

  • Key: KERML11-34
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 29 Jul 2023 14:44 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Default for the first operand of a classification expression

  • Key: KERML11-32
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.4.9.2 OperatorExpressions, in the bullet for "Classification expressions", it states:

    The classification operators may also be used without a first operand, in which case the first operand is implicitly Anything::self (see 9.2.2.2.1). This is useful, in particular, when used as a test within an element filter condition expression (see 7.4.14).

    In the concrete syntax, in 8.2.5.8.1 Operator Expressions, the production for ClassificationExpression does, indeed, allow the first operand to be optional. However, there is nothing stated there (or anywhere else in normative Clause 8) about the default for the first operand being Anything::self if it is not given explicitly, as stated in 7.4.9.2.

  • Reported: KerML 1.0a1 — Mon, 3 Jul 2023 23:00 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

validateAssociationStructureIntersection seems vacuous

  • Key: KERML11-33
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 11 Jul 2023 20:11 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Some package-level features are mandatory

  • Key: KERML11-29
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    [From Vince Molnar] Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

    Clocks::universalClock[1] {...}
    Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
    SpatialFrames::defaultFrame : SpatialFrame[1] {...}
    

    Might be others. This one

    Occurrences::earlierFirstIncomingTransferSort: IncomingTransferSort{... }
    

    does not give a multiplicity, I couldn't find what this means (even for expressions), tho this particular feature is supposed to have exactly one value.

  • Reported: KerML 1.0a1 — Mon, 1 May 2023 15:32 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Invariants only hold when evaluated

  • Key: KERML11-31
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clauses 7.4.8.1 (Functions Overview) and 8.4.4.8.2 (Expressions and Invariants) say

    An invariant, though, is a boolean expression that must always evaluate to either true at all times or false at all times. By default, an invariant is asserted to always evaluate to true, while a negated invariant is asserted to always evaluate to false.

    Expressions are kinds of Steps. The checkExpressionSpecialization constraint requires that Expressions specialize the base Expression Performances::evaluations (see 9.2.6.2.3), which is a specialization of Performances::performances.

    the checkInvariantSpecialization constraint requires that Invariants specialize either the BooleanExpression Performances::trueEvaluations (see 9.2.6.2.2) or, if the Invariant is negated, the BooleanExpression Performances::falseEvaluations (see 9.2.6.2.2), both of which are specializations of Performances::booleanEvaluations.

    where the Performance library defines

    abstract expr trueEvaluations subsets booleanEvaluations { true }
    
    abstract expr falseEvaluations subsets booleanEvaluations { false }
    

    but do not require models to specify when invariant expressions are evaluated, which are the only times the results are required to be true/false. The conditions they test for might be present only when the invariants happen to be evaluated (see KERML-58 for more about this).

  • Reported: KerML 1.0a1 — Fri, 5 May 2023 13:55 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Conditions missing for some sufficient library types

  • Key: KERML11-25
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Some library types are sufficient, but do give give any conditions. For example, in Occurrences::Occurrence::

    portion feature all portions: Occurrence[1..*] subsets spaceTimeEnclosedOccurrences { ... }
    

    only has text documentation between the curly braces, leaving sufficiency to mean that portions and spaceTimeEnclosedOccurrences are equivalent. Might be others like this.

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 14:56 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Machine readable project interchange file(s) for language description examples

  • Key: KERML11-28
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

  • Reported: KerML 1.0a1 — Sat, 29 Apr 2023 20:42 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

XMI and JSON for model libraries

  • Key: KERML11-26
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.kerml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 19:51 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Some types not given any semantics

  • Key: KERML11-27
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The Type metaclass is concrete (like all the metaclasses in the abstract syntax), making it it syntactically valid to create a Type that is not a Classifier or a Feature. However, Clause 8.4.3.1.2 (Core Semantics Mathematical Preliminaries) requires the set of Types in a model to be the union of the set of Classifiers and Features. This means instances of Type in a model that are not Classifiers or Features are syntactically valid, but not given semantics (it's not possible to tell if instances of such types are valid or not).

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 20:16 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Sufficiency missing for some library types

  • Key: KERML11-24
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Some library types might be intended to be sufficient. For example, in Occurrences::Occurrence, the values of

    feature spaceTimeCoincidentOccurrences: Occurrence[1..*] subsets timeCoincidentOccurrences, spaceEnclosedOccurrences ... { ...
      feature redefines thatOccurrence subsets largerSpace;
      feature redefines thisOccurrence subsets smallerSpace;
      connector :InsideOf from largerSpace references thatOccurrence [1]
                          to smallerSpace references thisOccurrence [1]; }
    

    presumably should include all timeCoincident/spaceEnclosedOccurrences that meet the condition given by the connector, but the feature is not marked as sufficient. Might be others like this.

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 14:50 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Decision/MergePerformance element descriptions give incorrect modeling pattern

  • Key: KERML11-22
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.2.9.1 (Control Performances Overview) says

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

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

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

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

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

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

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

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

  • Reported: KerML 1.0a1 — Mon, 24 Apr 2023 14:52 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Succession end multiplicity defaults not documented

  • Key: KERML11-23
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.4.6.2 (Binding Connectors) says

    binding f1 = f2;
    

    is equivalent to

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

    while the next clause, 8.4.4.6.3 (Successions) says

    succession first f1 then f2;
    

    is equivalent to

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

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

  • Reported: KerML 1.0a1 — Mon, 24 Apr 2023 15:07 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Steps are not always time enclosed

  • Key: KERML11-21
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.4.7.2 (Steps, under Behavior Semantics) says

    The checkStepSpecialization constraint requires that Steps specialize Performances::performances.

    checkStepEnclosedPerformanceSpecialization and checkStepSubperformanceSpecialization constraints require that a Step whose owningType is a Behavior or another Step specialize Performances::Performance::enclosedPerformance or, if it is composite, Performances::Performance::subperformance.

    checkStepOwnedPerformanceSpecialization constraint requires that a composite Step whose owningType is a Structure or a Feature typed by a Structure specialize Objects::Object::ownedPerformance.

    where enclosedPerformances, subperformances, and ownedPerformances (in)directly subset timeEnclosedOccurrences, the values of which happen during the occurrences "having" the value.

    The first constraint leaves open the possibility that steps might not happen during the occurrences they are steps of, bc Performances::performances is a step and subsets occurrences, rather than timeEnclosedOccurrences. This conflicts with the normal meaning of the term "step" (a terminology issue), which typically connotes (in library terms) performances that happen during the occurrences they are steps of.

    The second constraint prevents the possibility above for steps owned by behaviors or other steps, while the third only prevents it for composite steps owned by structures.

    The step keyword looks like it's sometimes used with other intentions than the constraints indicate. For example, in Observation.kerml:

    behavior ObserveChange { ...
      step transfer : TransferBefore[1] ... {
        /* Then send changeSignal to changeObserver. */ ... } ... }
    

    ↑ Is it intended that observechange occurrences timeenclose the entire transfer (all the way to it's arrival at its target), as required by the second constraint?

    struct ChangeMonitor { ...
      step startObservation { ... }
      step cancelObservation { ... }
    

    ↑ Is it intended that the values of start/CancelObservation can happen at other times than the ChangeMonitor occurrence referencing them, as allowed by the third constraint?

    Transfers::
      step transfers: Transfer[0..*] nonunique subsets performances, binaryLinks { ... }
      step messageTransfers: MessageTransfer[0..*] nonunique subsets transfers { ... }
      step flowTransfers: FlowTransfer[0..*] nonunique subsets transfers { ... }
      step transfersBefore: TransferBefore[0..*] nonunique subsets transfers, happensBeforeLinks { ... }
      step flowTransfersBefore: FlowTransferBefore[0..*] nonunique subsets flowTransfers, transfersBefore { ... }
    

    ↑ These are features of (effectively) Anything, including structures and behaviors, so sometimes they'll be time enclosed and sometimes not. For example:

    Occurrence::
      feature incomingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }
      feature outgoingTransfers: Transfers::Transfer[0..*] subsets Transfers::transfers { ... }
    

    ↑ will be time enclosed for transfers into/out of performances, but not objects, assuming the above are redefined as steps in behaviors or structures (or that features specialized from steps are also steps).

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 15:22 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

direction, semantics

  • Key: KERML11-20
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Feature direction (Feature::direction:FeatureDirectionKind) is described as

    in, out, inout: Specifies the direction of a feature, which determines what is allowed to change its values on instances of its domain:
    -in: Things "outside" the instance. These features identify things input to an instance.
    -out: The instance itself or things "inside" it. These features identify things output by an instance.
    -inout: Both things "outside" and "inside" the instance. These features identify things that are both input to and output by an instance.

    but this semantics is not math/modeled and depends on Kernel for instances changing over time.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 13:19 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT
  • Attachments:

isSufficient, semantics, expressiveness

  • Key: KERML11-19
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Sufficient types are (Type::isSufficient=true) are described as

    A type gives conditions for what things must be in or not in its extent (sufficient and necessary conditions, respectively).

    ... the type places additional sufficiency conditions on its instances corresponding to all the necessary conditions.

    but this semantics is not math/modeled and the syntax cannot specify that only some necessary conditions are to correspond to sufficient ones.

  • Reported: KerML 1.0a1 — Sun, 16 Apr 2023 16:43 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Classifier multiplicity, semantics

  • Key: KERML11-14
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type. For a feature f, the values of its multiplicity (as a feature) are allowed cardinalities for the collection of values on each instance of f 's featuring type, while for classifiers they are allowed cardinalities for the collection of its instances. Math semantics for feature multiplicity is available (rule 5 in 8.4.3.4, Features Semantics), but missing for classifier multiplicity. Is it intended that every instance of a classifier give the number of allowable instances of that classifier? What if there are no instances?

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 19:06 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

isPortion, semantics

  • Key: KERML11-17
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Portion features (Feature::isPortion=true) are described as

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

    but this semantics is not math/modeled, at least not in Core, which does not include models of time or space. A syntactic constraint that isPortion implies isComposite also seems to be missing.

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 20:18 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Dynamic multiplicity, semantics

  • Key: KERML11-15
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Multiplicity is a feature of a type (feature or classifier), with natural numbers as its type (see description of KERML-1). The math semantics for feature multiplicity (rule 5 in 8.4.3.4, Features Semantics) refers to the multiplicity metaproperty on a feature f as model element, rather than the multiplicity feature on an instance of f 's featuring type, preventing it from covering multiplicity values that change over the life of an instance, and possibly not handling constant values either.

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 19:32 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

isReadOnly, semantics

  • Key: KERML11-16
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

    but this semantics is not model/mathed and depends on Kernel for instances existing in time.

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

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 20:02 GMT
  • Updated: Fri, 20 Jun 2025 22:13 GMT

Missing descriptions of specialized effective naming

  • Key: SYSML21-7
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Wed, 18 Jun 2025 20:52 GMT
  • Updated: Fri, 20 Jun 2025 19:36 GMT

Editorial mistake in explanation of composite or portion feature

  • Key: KERML11-13
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

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

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

  • Reported: KerML 1.0b2 — Tue, 15 Apr 2025 13:59 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

checkConnectorTypeFeaturing fails on implied BindingConnector of a FeatureReferenceExpression

  • Key: KERML11-8
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Wed, 7 May 2025 22:46 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Typo in documentation of Transfer::isInstant

  • Key: KERML11-9
  • Status: open  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

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

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

  • Reported: KerML 1.0b2 — Wed, 30 Apr 2025 11:27 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Filtering is not applied on imported packages

  • Key: KERML11-12
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0b2 — Thu, 1 May 2025 21:20 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

isCompatibleWith operation needs a return type

  • Key: KERML11-11
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Sat, 3 May 2025 21:30 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

keywords 'standard' and 'library' are missing in list of keywords

  • Key: KERML11-10
  • Status: open  
  • Source: rptu.de ( Prof. Christoph Grimm)
  • Summary:

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

  • Reported: KerML 1.0b2 — Tue, 29 Apr 2025 19:22 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Error in constraint checkMultiplicityTypeFeaturing

  • Key: KERML11-4
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 19 Jun 2025 21:30 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Error in constraint checkFeatureParameterRedefinition

  • Key: KERML11-6
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

  • Reported: KerML 1.0b2 — Sat, 14 Jun 2025 17:11 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Featuring type of the multiplicity of a cross feature

  • Key: KERML11-3
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 19 Jun 2025 21:41 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Occurrences::surroundedByOccurrences::surroundingSpace should not be an end feature

  • Key: KERML11-2
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    end [1] feature surroundingSpace: Occurrence subsets self;
    

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

  • Reported: KerML 1.0b2 — Thu, 19 Jun 2025 23:05 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Error in constraint deriveFeatureFeaturingType

  • Key: KERML11-7
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 22 May 2025 13:48 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT

Binding connectors should not be considered owned cross features

  • Key: KERML11-1
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Thu, 19 Jun 2025 23:17 GMT
  • Updated: Fri, 20 Jun 2025 19:32 GMT