Kernel Modeling Language Avatar
  1. OMG Specification

Kernel Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
KERML_-132 Constructor invocation expressions are semantically inconsistent KerML 1.0b2 open
KERML_-104 Transitivity missing for some time/space associations KerML 1.0b2 open
KERML_-161 Typo in description of namespace KerML 1.0b2 open
KERML_-107 The term "Item" in KerML confusing against SysML KerML 1.0b2 open
KERML_-59 OCL for checkFeatureParameterRedefinition is wrong KerML 1.0b2 open
KERML_-145 Select Expression result parameter implicit subsetting produced by reference implementationnot defined in specification KerML 1.0b2 open
KERML_-146 Need to revise derivation of AnnotatingElement::ownedAnnotatingRelationship KerML 1.0b2 open
KERML_-151 Corrections to the resolution of KERML_-39 KerML 1.0b2 open
KERML_-144 # expression result parameter implicit subsetting produced by reference implementationnot defined in specification KerML 1.0b2 open
KERML_-162 MetadataAccessExpression::referencedElement should be derived KerML 1.0b2 open
KERML_-165 Use of memberName in OwningMembership KerML 1.0b2 open
KERML_-117 InvocationExpression::result specialization KerML 1.0b2 open
KERML_-72 Editorial errors in constraints KerML 1.0b2 open
KERML_-159 n>2-ary link ends not readonly KerML 1.0b2 open
KERML_-119 Navigability of AnnotatingElement<->Annotation meta-association KerML 1.0b2 open
KERML_-99 CheckFeatureChainExpressionResultSpecialization constraint needs to be defined KerML 1.0b2 open
SYSML2_-486 ShapeItems can't be SpatialItems KerML 1.0b2 open
KERML_-154 Space and time slice descriptions are the same KerML 1.0b2 open
KERML_-140 MultiplicityRanges should allow owned members other than bounds KerML 1.0b2 open
KERML_-120 Recursive import with includeAll = true should recurse through private packages KerML 1.0b2 open
KERML_-84 Type::directionOf does not handle inheritence from feature chains KerML 1.0b2 open
KERML_-68 deriveExpressionResult and deriveFunctionResult should be revised KerML 1.0b2 open
KERML_-147 Incorrect succession in state and transition library KerML 1.0b2 open
KERML_-73 Disallow public imports at root level KerML 1.0b2 open
KERML_-88 Problem with the property name "targetFeature" KerML 1.0b2 open
SYSML2_-418 Message Connector Ends are Absent by Default; If Ends are Specified, Message is Indistinguishable from Flow KerML 1.0b2 open
KERML_-121 Incorrect metadata example KerML 1.0b2 open
KERML_-115 Error in specification of library model UUIDs KerML 1.0b2 open
KERML_-94 Interpretation 3-tuple described as 2-tuple KerML 1.0b2 open
KERML_-92 Interpretation function co-domain expressed incorrectly KerML 1.0b2 open
KERML_-90 Problem with validateImportTopLevelVisibility constraint KerML 1.0b2 open
KERML_-106 Problem with nested feature semantics KerML 1.0b2 open
KERML_-100 Eliminate EndFeatureMembership and ParameterMembership from abstract syntax KerML 1.0b2 open
KERML_-74 Make imports private by default KerML 1.0b2 open
KERML_-98 HappensLink disjointness documentation inconsistent KerML 1.0b2 open
KERML_-96 TransferBefore is unsatisfiable KerML 1.0b2 open
KERML_-75 Restrict the functionality of recursive import KerML 1.0b2 open
KERML_-70 The OCL for isFeaturedWithin is still not correct KerML 1.0b2 open
KERML_-69 relationship not defined KerML 1.0b2 open
KERML_-67 Invocation of a non-function behavior KerML 1.0b2 open
KERML_-65 isOrdered and isUnique are missing from the reflective abstract mapping KerML 1.0b2 open
KERML_-63 FeatureIdentificationProduction is incorrect KerML 1.0b2 open
KERML_-61 Incorrect binding syntax in Feature Values Semantics KerML 1.0b2 open
KERML_-85 Impossible to specialize (redefine, subset) unnamed features in textual syntax KerML 1.0b2 open
KERML_-83 CollectExpression and SelectExpression should not reference BodyExpressionMember KerML 1.0b2 open

Issues Descriptions

Constructor invocation expressions are semantically inconsistent

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

    8.4.4.9.4 Invocation Expressions states that:

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

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

  • Reported: KerML 1.0b2 — Mon, 16 Dec 2024 22:41 GMT
  • Updated: Wed, 12 Feb 2025 21:48 GMT

Transitivity missing for some time/space associations

  • Key: KERML_-104
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b2 — Sat, 31 Aug 2024 18:42 GMT
  • Updated: Wed, 12 Feb 2025 19:52 GMT

Typo in description of namespace

  • Key: KERML_-161
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

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

    I think this should be ownedMemberName and ownedMemberShortName

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

  • Reported: KerML 1.0b2 — Sat, 8 Feb 2025 11:33 GMT
  • Updated: Wed, 12 Feb 2025 19:48 GMT

The term "Item" in KerML confusing against SysML

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

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

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

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

  • Reported: KerML 1.0b2 — Wed, 11 Sep 2024 16:49 GMT
  • Updated: Wed, 12 Feb 2025 18:50 GMT

OCL for checkFeatureParameterRedefinition is wrong

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

    The description of the checkFeatureParameterRedefinition constraint is

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

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

  • Reported: KerML 1.0b2 — Wed, 17 Apr 2024 19:50 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

Select Expression result parameter implicit subsetting produced by reference implementationnot defined in specification

  • Key: KERML_-145
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:
    package p {
        part b {
            part B;
        }
        part A :> b;
        e = A.? { }.B;
    }
    

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

  • Reported: KerML 1.0b2 — Tue, 10 Dec 2024 17:42 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

Need to revise derivation of AnnotatingElement::ownedAnnotatingRelationship

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

    The current derivation constraint for AnnotatingElement::ownedAnnotatingRelationship is

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

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

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

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

  • Reported: KerML 1.0b2 — Thu, 9 Jan 2025 21:57 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

Corrections to the resolution of KERML_-39

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

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

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

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

  • Reported: KerML 1.0b2 — Tue, 14 Jan 2025 22:00 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

# expression result parameter implicit subsetting produced by reference implementationnot defined in specification

  • Key: KERML_-144
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:
    package ShapeItems {
        part equals;
        item edges {
            item vertices;
        }
        assert constraint {
            in i;
            edges#(i).vertices->equals()
        }
    }
    

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

  • Reported: KerML 1.0b2 — Tue, 10 Dec 2024 17:22 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

MetadataAccessExpression::referencedElement should be derived

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

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

  • Reported: KerML 1.0b2 — Sun, 9 Feb 2025 21:03 GMT
  • Updated: Wed, 12 Feb 2025 05:55 GMT

Use of memberName in OwningMembership

  • Key: KERML_-165
  • Status: open  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

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

    {redefines memberName}

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

  • Reported: KerML 1.0b2 — Sun, 9 Feb 2025 11:56 GMT
  • Updated: Tue, 11 Feb 2025 14:01 GMT

InvocationExpression::result specialization

  • Key: KERML_-117
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

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

  • Reported: KerML 1.0b2 — Mon, 28 Oct 2024 07:39 GMT
  • Updated: Fri, 7 Feb 2025 20:57 GMT
  • Attachments:

Editorial errors in constraints

  • Key: KERML_-72
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:
    1. In 8.3.3.3.10 Subsetting, in the description of validateSubsettingUniquenessConformance, change the second occurrence of subsettedFeature to subsettingFeature.
    2. In 8.3.4.5.3 Connector, in the OCL for checkConnectorBinaryObjectSpecialization, "AssocationStructure" should be "AssociationStructure".
    3. In 8.3.4.5.4 Succession, in the OCL for checkSuccessionSpecialization, "Occurences" should be "Occurrences".
  • Reported: KerML 1.0b2 — Fri, 3 May 2024 18:58 GMT
  • Updated: Fri, 7 Feb 2025 20:53 GMT

n>2-ary link ends not readonly

  • Key: KERML_-159
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b2 — Mon, 3 Feb 2025 17:03 GMT
  • Updated: Mon, 3 Feb 2025 17:04 GMT

Navigability of AnnotatingElement<->Annotation meta-association

  • Key: KERML_-119
  • Status: open  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    Annotation relationship creation modifies navigable AnnotatingElement::annotation property.

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

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

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

  • Reported: KerML 1.0b2 — Mon, 28 Oct 2024 08:15 GMT
  • Updated: Thu, 30 Jan 2025 20:20 GMT
  • Attachments:

CheckFeatureChainExpressionResultSpecialization constraint needs to be defined

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

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

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

    The line part g = f.a parses into:

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

  • Reported: KerML 1.0b2 — Tue, 30 Jul 2024 12:15 GMT
  • Updated: Thu, 30 Jan 2025 20:07 GMT
  • Attachments:
    • p.png 294 kB (image/png)

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: Sun, 26 Jan 2025 16:16 GMT

Space and time slice descriptions are the same

  • Key: KERML_-154
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

    while the second paragraph starts

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

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

  • Reported: KerML 1.0b2 — Wed, 15 Jan 2025 20:52 GMT
  • Updated: Sat, 18 Jan 2025 18:40 GMT

MultiplicityRanges should allow owned members other than bounds

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

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

  • Reported: KerML 1.0b2 — Fri, 27 Dec 2024 06:26 GMT
  • Updated: Tue, 14 Jan 2025 00:49 GMT

Recursive import with includeAll = true should recurse through private packages

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

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

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

  • Reported: KerML 1.0b2 — Tue, 29 Oct 2024 20:19 GMT
  • Updated: Tue, 14 Jan 2025 00:49 GMT

Type::directionOf does not handle inheritence from feature chains

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

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

    For example, consider the model

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

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

  • Reported: KerML 1.0b2 — Wed, 22 May 2024 21:36 GMT
  • Updated: Tue, 14 Jan 2025 00:48 GMT

deriveExpressionResult and deriveFunctionResult should be revised

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

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

    The description of deriveExpressionResult states that

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

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

    Somewhat similarly, the description of the constraint deriveFunctionResult states that

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

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

  • Reported: KerML 1.0b2 — Mon, 22 Apr 2024 12:55 GMT
  • Updated: Tue, 14 Jan 2025 00:48 GMT

Incorrect succession in state and transition library

  • Key: KERML_-147
  • 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: Sat, 11 Jan 2025 12:28 GMT
  • Attachments:

Disallow public imports at root level

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

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

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

    package Namespace1 {
        classifier A;
        classifier B;
    }
    
    public import Namespace1::*;
    package Namespace2 {
       ...
    }
    
    public import Namespace1::*;
    package Namespace3 {
       ...
    }
    

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

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

  • Reported: KerML 1.0b2 — Sun, 5 May 2024 23:30 GMT
  • Updated: Thu, 2 Jan 2025 18:39 GMT

Problem with the property name "targetFeature"

  • Key: KERML_-88
  • Status: open   Implementation work Blocked
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b2 — Tue, 16 Jul 2024 20:29 GMT
  • Updated: Thu, 2 Jan 2025 18:22 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: Tue, 17 Dec 2024 22:54 GMT

Incorrect metadata example

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

    In 7.4.13 Metadata, the very last example is the declaration

    #SecurityRelated #command def Save;

    However, def is not a KerML keyword.

  • Reported: KerML 1.0b2 — Tue, 5 Nov 2024 16:50 GMT
  • Updated: Tue, 26 Nov 2024 00:50 GMT

Error in specification of library model UUIDs

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

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

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

Interpretation 3-tuple described as 2-tuple

  • Key: KERML_-94
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

    The bullets after this describe three elements for I.

  • Reported: KerML 1.0b2 — Wed, 24 Jul 2024 17:25 GMT
  • Updated: Tue, 26 Nov 2024 00:50 GMT

Interpretation function co-domain expressed incorrectly


Problem with validateImportTopLevelVisibility constraint

  • Key: KERML_-90
  • Status: open   Implementation work Blocked
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0b2 — Wed, 17 Jul 2024 03:52 GMT
  • Updated: Tue, 26 Nov 2024 00:50 GMT

Problem with nested feature semantics

  • Key: KERML_-106
  • 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: Mon, 9 Sep 2024 16:29 GMT

Eliminate EndFeatureMembership and ParameterMembership from abstract syntax

  • Key: KERML_-100
  • 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, 30 Aug 2024 22:14 GMT

Make imports private by default

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

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

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

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

  • Reported: KerML 1.0b2 — Mon, 6 May 2024 03:49 GMT
  • Updated: Wed, 31 Jul 2024 22:30 GMT

HappensLink disjointness documentation inconsistent

  • Key: KERML_-98
  • 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: Mon, 29 Jul 2024 19:51 GMT

TransferBefore is unsatisfiable

  • Key: KERML_-96
  • 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: Mon, 29 Jul 2024 19:24 GMT

Restrict the functionality of recursive import

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

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

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

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

    1. Require recursive imports to be private.
    2. Only recurse on owned Namespaces.
    3. Do not included Memberships that are inherited via implied Specializations.
  • Reported: KerML 1.0b2 — Mon, 6 May 2024 04:20 GMT
  • Updated: Sat, 6 Jul 2024 15:43 GMT

The OCL for isFeaturedWithin is still not correct

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

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

  • Reported: KerML 1.0b2 — Fri, 3 May 2024 18:48 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

relationship not defined

  • Key: KERML_-69
  • Status: open  
  • Source: Private ( Anders Reggestad)
  • Summary:

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

  • Reported: KerML 1.0b2 — Fri, 19 Apr 2024 20:28 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

Invocation of a non-function behavior

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

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

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

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

    behavior B {in x; out y; out z;}
    feature y1 = B(1).y;
    feature b = B(2);
    feature y2 = b.y;
    feature z2 = b.z;
    
  • Reported: KerML 1.0b2 — Wed, 17 Apr 2024 22:17 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

isOrdered and isUnique are missing from the reflective abstract mapping

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

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

  • Reported: KerML 1.0b2 — Wed, 17 Apr 2024 21:12 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

FeatureIdentificationProduction is incorrect

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

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

  • Reported: KerML 1.0b2 — Wed, 17 Apr 2024 20:36 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

Incorrect binding syntax in Feature Values Semantics

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

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

    member binding f = e.result featured by T;

    and the fourth snippet:

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

    These are both syntactically incorrect. The correct syntax is:

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

    and

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

  • Reported: KerML 1.0b2 — Wed, 17 Apr 2024 20:13 GMT
  • Updated: Tue, 28 May 2024 00:12 GMT

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

  • Key: KERML_-85
  • 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: Mon, 27 May 2024 03:02 GMT

CollectExpression and SelectExpression should not reference BodyExpressionMember

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

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

  • Reported: KerML 1.0b2 — Tue, 21 May 2024 15:50 GMT
  • Updated: Tue, 21 May 2024 15:50 GMT