Kernel Modeling Language Avatar
  1. OMG Specification

Kernel Modeling Language — Closed Issues

  • Acronym: KerML
  • Issues Count: 296
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
KERML_-224 Corrections to Ballot #5 resolutions KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-107 The term "Item" in KerML confusing against SysML KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-132 Constructor invocation expressions are semantically inconsistent KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-57 Time and space life/slice/portion modeling patterns are missing KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-162 MetadataAccessExpression::referencedElement should be derived KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-1 isEnd of the redefining feature must match isEnd of the redefined feature KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-146 Need to revise derivation of AnnotatingElement::ownedAnnotatingRelationship KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-104 Transitivity missing for some time/space associations KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-220 Corrections to the resolution of KERML_-18 KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-161 Typo in description of namespace KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-165 Use of memberName in OwningMembership KerML 1.0b2 KerML 1.0b4 Closed; No Change closed
KERML_-154 Space and time slice descriptions are the same KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-159 n>2-ary link ends not readonly KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-151 Corrections to the resolution of KERML_-39 KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-160 subsets of scalarQuantities should be nonunique SysML 2.0b2 KerML 1.0b4 Closed; No Change closed
KERML_-117 InvocationExpression::result specialization KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-145 Select Expression result parameter implicit subsetting produced by reference implementationnot defined in specification KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-144 # expression result parameter implicit subsetting produced by reference implementationnot defined in specification KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-143 ownedParameterMember should be ownedMemberParameter SysML 2.0b2 KerML 1.0b4 Resolved closed
KERML_-86 Confusing "Classes" with "Structures" KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-142 two haves SysML 2.0b1 KerML 1.0b4 Resolved closed
KERML_-101 Global scope notation SysML 2.0b2 KerML 1.0b4 Resolved closed
KERML_-49 Composite feature values can have more than one owner KerML 1.0b1 KerML 1.0b4 Duplicate or Merged closed
KERML_-83 CollectExpression and SelectExpression should not reference BodyExpressionMember KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-59 OCL for checkFeatureParameterRedefinition is wrong KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-5 isComposite, semantics KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-41 TransitionPerformance modeling pattern more general than needed, not aligned with SysML::TransitionUsage KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-47 Read only, misleading keyword, metaproperty name KerML 1.0b1 KerML 1.0b4 Duplicate or Merged closed
KERML_-222 validateParameterMembershipOwningType will fail for ConstructorExpressions KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-24 Performance & Object self redefinition missing in specification document KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-35 FeatureMembership owningType attribute ambiguity KerML 1.0b1 KerML 1.0b4 Closed; No Change closed
KERML_-36 KerML Libraries' elements shall have an elementId defined KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-72 Editorial errors in constraints KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-39 Type::inheritedMemberships OCL is missing KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-18 Redundancy in association end multiplicities, ordering, and uniqueness KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-119 Navigability of AnnotatingElement<->Annotation meta-association KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-99 CheckFeatureChainExpressionResultSpecialization constraint needs to be defined KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-140 MultiplicityRanges should allow owned members other than bounds KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-84 Type::directionOf does not handle inheritence from feature chains KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-68 deriveExpressionResult and deriveFunctionResult should be revised KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-120 Recursive import with includeAll = true should recurse through private packages KerML 1.0b2 KerML 1.0b4 Duplicate or Merged closed
KERML_-73 Disallow public imports at root level KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-88 Problem with the property name "targetFeature" KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-37 Add derived property for targetFeature KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-115 Error in specification of library model UUIDs KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-94 Interpretation 3-tuple described as 2-tuple KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-32 Association ends can have more than one type KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-121 Incorrect metadata example KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-90 Problem with validateImportTopLevelVisibility constraint KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-92 Interpretation function co-domain expressed incorrectly KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-42 Association end feature description missing simple example and equivalence to related types KerML 1.0b1 KerML 1.0b4 Duplicate or Merged closed
KERML_-20 Nary association end multiplicity, semantics KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-21 Association end features are not necessarily consistent with corresponding features of associated classifiers KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-28 Connector ends cannot give smaller lower multiplicity than their association ends KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-16 Association participant features, misleading term and textual keyword KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-19 Context-dependent meanings for feature multiplicity, ordering, and uniqueness KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-17 Number of association end feature values, semantics KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-8 Type union, intersection, difference semantics KerML 1.0a1 KerML 1.0b4 Resolved closed
KERML_-12 End feature multiplicity textual notation KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-13 Some bindings have optional connector end multiplicities KerML 1.0a1 KerML 1.0b4 Duplicate or Merged closed
KERML_-74 Make imports private by default KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-75 Restrict the functionality of recursive import KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-52 Semantic constraint needed for result type of a "constructor" expression KerML 1.0b1 KerML 1.0b4 Resolved closed
KERML_-70 The OCL for isFeaturedWithin is still not correct KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-67 Invocation of a non-function behavior KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-69 relationship not defined KerML 1.0b2 KerML 1.0b4 Closed; No Change closed
KERML_-61 Incorrect binding syntax in Feature Values Semantics KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-63 FeatureIdentificationProduction is incorrect KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-65 isOrdered and isUnique are missing from the reflective abstract mapping KerML 1.0b2 KerML 1.0b4 Resolved closed
KERML_-2 Classifier multiplicity, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-3 Dynamic multiplicity, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-4 isReadOnly, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-6 isPortion, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-7 isAbstract, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-10 direction, semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-9 isSufficient, semantics, expressiveness KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-11 Steps are not always time enclosed KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-14 Decision/MergePerformance element descriptions give incorrect modeling pattern KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-15 Succession end multiplicity defaults not documented KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-22 Sufficiency missing for some library types KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-23 Conditions missing for some sufficient library types KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-25 XMI and JSON for model libraries KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-26 Some types not given any semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-29 Some package-level features are mandatory KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-27 Machine readable project interchange file(s) for language description examples KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-30 Feature values do not specify when their expressions are evaluated KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-31 Invariants only hold when evaluated KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-33 Default for the first operand of a classification expression KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-34 validateAssociationStructureIntersection seems vacuous KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-38 Inherited multiplicities, semantics KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-40 Add validateSubsettingTypeConformance constraint KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-43 Root namespaces restricted to one single file KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-44 Ambiguity In Directionality InOut semantics KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-45 Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-46 Serious limitation of textual concrete syntax as model interchange format KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-48 Annex A coverage KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-51 TimeOf::timeContinuityConstraint might be too restrictive KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-50 Some syntax in Core has time-dependent semantics KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML_-53 KerML should have syntax for enumerations SysML 2.0b1 KerML 1.0b4 Deferred closed
KERML_-54 isDerived, semantics KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-85 Impossible to specialize (redefine, subset) unnamed features in textual syntax KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-56 Space triggers missings KerML 1.0b1 KerML 1.0b4 Deferred closed
KERML_-96 TransferBefore is unsatisfiable KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-98 HappensLink disjointness documentation inconsistent KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-100 Eliminate EndFeatureMembership and ParameterMembership from abstract syntax KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-147 Incorrect succession in state and transition library KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-106 Problem with nested feature semantics KerML 1.0b2 KerML 1.0b4 Deferred closed
KERML_-55 Discrepancy between documentation of Collections library in spec and textual notation file KerML 1.0a1 KerML 1.0b4 Deferred closed
KERML-46 Intersection missing for some multiple specializations KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-82 checkConnectorTypeFeaturing is not correct KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-98 Comment Locale not in textual notation KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-120 FlowTransferBefore needs end feature declarations KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-110 Disjoining example conflicts with textual description KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-125 specializesFromLibrary arguments use inconsistent notation for strings KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-45 LinkObject is irreflexive KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-282 Measuring devices for space missing KerML 1.0b1 KerML 1.0b2 Closed; No Change closed
KERML-307 User-defined keywords are not allowed on metadata features KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-234 Features successors and predecessors of Occurrence should be disjoint KerML 1.0a1 KerML 1.0b2 Closed; No Change closed
KERML-309 package "Interactions TBD" should not be included in the XMI file KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-165 Exponentiation should be right-associative KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-174 DataType Disjointness Clarification KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-22 Name all associations in the KerML abstract syntax KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-23 Follow typographical conventions in the KerML Metamodel clause KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-75 Specify default direction for the ownedParameterMember of a ParameterMembership KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-259 Reference to nonexistent class (Superclassification) in OCL rule deriveClassifierOwnedSubclassification KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-139 OclisKindOf applied to Namespace::resolve() KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-21 Add a property for Annotations owned by an AnnotatingElement KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-7 isDirected, definition, semantics KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-154 Directed features inherited from a conjugated type not handled properly KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-199 validateMultiplicityRangeBoundResultTypes constraint is too strong KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-161 Misspelling KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-231 LinkObject disjointness is redundant KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-49 Some readonly features are intended to have changing values KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-251 Remove disjointness of LinkObject KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-260 Definition of property "typing" seems incomplete/inconsistent KerML 1.0b1 KerML 1.0b2 Closed; No Change closed
KERML-239 SelfLink::thatThing does not exist in Links Model Library KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-249 Typo in Function Abstract Syntax Description KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-250 Typo in Function Declaration Overview KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-61 PrimaryExpressionMember production should generate a ParameterMembership KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-186 Update semantic model of invariants for validateExpressionResultExpressionMembership constraint KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-237 Link Participant Plurality Typo in OCL KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-238 No textual syntax or derivation rules for isDirected KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-241 Typo in Multiplicity Ranges Semantics KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-240 Typo in Multiplicities Overview KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-242 Typo in checkAssociationBinarySpecialization OCL KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-247 Typo in modelLevelEvaluable Operation text KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-248 Error in Expression modelLevelEvaluable operation OCL KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-200 Annex A (Model Execution) minor errors KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-232 Additional problems with deriveFeatureType KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-236 Association SourceType Cardinality Contradiction KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-192 Many mistakes and differences to implementation KerML 1.0b1 KerML 1.0b2 Closed; No Change closed
KERML-194 validateRedefinitionDirectionConformance does not account for conjugation KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-193 Weird Concrete Syntax for ConditionalExpression KerML 1.0b1 KerML 1.0b2 Closed; No Change closed
KERML-171 Feature Chain relationships are inconsistent with the concrete syntax KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-172 ClassifierDeclaration concrete syntax typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-173 Classifier Description Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-179 checkAssociationStructureSpecialization invalid reference KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-189 non-terminal does not exist in the specification KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-181 Model Interchange Overview Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-191 Comment textual syntax defined differently to implementation KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-190 OwnedExpression missing ConditionalBinaryOperatorExpression KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-114 FeatureDeclaration ConjugationPart lexical element incorrect reference KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-162 Misidentified non-terminals and misspelled non-terminals in the EBNF KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-160 unknown non-terminal reference in EBNF KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-164 No production for nonterminal KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-167 Typo in Conjugation Description KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-170 checkFeatureSubobjectSpecialization incorrect Font KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-169 Feature isDerived metaproperty Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-106 Protected membership inheritance through Specialization type KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-109 Textual Syntax allows multiple ConjugationParts on a Type KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-108 Conjugation Textual Redundant Word KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-111 Disjoining textual notation typo on disjoiningType KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-138 oclAsType applied to resolveGlobal KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-155 Expression::result has an incorrect subsetting API4KP 1.0b2 KerML 1.0b2 Resolved closed
KERML-158 InsideOf association end feature redefines cross feature KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-54 Subsetting::/owningType is mandatory KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-62 Occurrences do not identify local spatial frame KerML 1.0a1 KerML 1.0b2 Closed; No Change closed
KERML-90 The MetadataFeature::metaclass multiplicity is too restrictive KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-105 Car necessary and sufficiency example KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-104 Type Membership Multiplicity text conflict KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-39 Link participant feature called an association end KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-56 Universal features can have many values KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-44 Spatial links can be occurrences KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-59 KerML 7.4.7.2 Behavior Declaration: last example KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-24 Connector declaration does not allow a feature value KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-43 Performances can be objects, behaviors can be structures KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-25 Reflective KerML abstract syntax model has inconsistencies KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-178 Anything.self subsetting Inconsistent declaration with Base.kerml declaration KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-198 Wrong documentation format for class Occurrence in Semantic Library KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-182 Update Kernel Semantic Library for validateRedefinitionDirectionConformance constraint KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-227 Documentation of features in Transfers library model is wrong KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-20 Validation constraints are missing in the KerML abstract syntax KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-42 Occurrences can be data values KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-184 Update Kernel Model Libraries for validateFeatureValueOverriding constraint KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-188 DataFunctions::Min and Max should not be capitalized KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-195 Transfer sourceOutput and targetInput directions KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-77 Problems with IfThenElsePerformance KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-88 BaseFunctions::',' has a bad parameter declaration KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-38 Binary association ends always unique KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-175 Natural unnecessary explicit general type declaration KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-176 Base Overview Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-177 Legacy, so incorrect, wording in Anything Description KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-180 Occurrences Overview Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-151 deriveFeatureType is not correct KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-112 deriveTypeOwned TypeRelationship constraints have incomplete OCL KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-117 deriveTypeFeatureMembership incorrect unioning KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-118 deriveFeatureFeaturingType conflicts with owningType KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-122 validateClassSpecialization is too strict KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-12 OCL errors in validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-18 Semantic constraints for subtypes of LiteralExpression are missing KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-100 Namespace Description Textual Errors KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-99 deriveMembershipMemberElementId text elementId typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-102 OwningMembership Description ownedMemberElement typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-107 validateSpecificationSpecificNotConjugated Typo and over Constraint KerML 1.0b1 KerML 1.0b2 Duplicate or Merged closed
KERML-103 deriveElementIsLibraryElement Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-113 deriveFeatureOwnedSubsetting text references wrong attribute KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-96 validateSpecializationSpecificNotConjugated documentation is wrong KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-115 FeatureMembership Description Typo KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-83 OCL errors in specialization constraints KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-89 The checkFeatureValuationSpecialization constraint is incorrect KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-94 The description of deriveFeatureReferenceExpressionReferent is wrong KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-101 NamespaceImport Description Incorrect KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-19 The checkFeatureEndSpecialization constraint should apply to Connectors as well as Associations KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-95 validateTypeAtMostOneConjugator OCL is wrong KerML 1.0b1 KerML 1.0b2 Resolved closed
KERML-60 7.4.1 Kernel Overview: Occurence instead of Object superclass KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-78 Some Feature constraints have no description KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-64 Typo in 7.4.7.2 KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-80 Incorrect OCL for validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-13 validateRedefinitionFeaturingTypes documentation and constraint are wrong KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-17 The OCL for checkFeatureEndRedefinition is wrong KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-31 Typo in Grammar KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-65 Typo in description of Connector::targetFeature KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-14 validateItemFlowItemFeature documentation is wrong KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-16 Rename validateDatatypeSpecialization to validateDataTypeSpecialization KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-15 Names validatePackageFilterIsBoolean and validatePackageFilterIsModelEvaluable are wrong KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-30 List of symbols incomplete KerML 1.0a1 KerML 1.0b2 Resolved closed
KERML-32 Validation constraints are missing in the SysML abstract syntax KerML 1.0a1 KerML 1.0b2 Transfered closed
KERML-1 Classifier multiplicity, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-2 Dynamic multiplicity, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-4 isComposite, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-3 isReadOnly, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-5 isPortion, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-6 isAbstract, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-8 Type union, intersection, difference semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-9 isSufficient, semantics, expressiveness KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-11 Steps are not always time enclosed KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-10 direction, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-26 End feature multiplicity textual notation KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-27 Some bindings have optional connector end multiplicities KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-28 Decision/MergePerformance element descriptions give incorrect modeling pattern KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-29 Succession end multiplicity defaults not documented KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-34 Association participant features, misleading term and textual keyword KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-35 Number of association end feature values, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-36 Redundancy in association end multiplicities, ordering, and uniqueness KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-37 Context-dependent meanings for feature multiplicity, ordering, and uniqueness KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-40 Nary association end multiplicity, semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-41 Association end features are not necessarily consistent with corresponding features of associated classifiers KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-47 Sufficiency missing for some library types KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-48 Conditions missing for some sufficient library types KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-50 Performance & Object self redefinition missing in specification document KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-51 XMI and JSON for model libraries KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-55 Connector ends cannot give smaller lower multiplicity than their association ends KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-52 Some types not given any semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-57 Some package-level features are mandatory KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-53 Machine readable project interchange file(s) for language description examples KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-58 Feature values do not specify when their expressions are evaluated KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-63 Invariants only hold when evaluated KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-76 Association ends can have more than one type KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-93 Default for the first operand of a classification expression KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-116 FeatureMembership owningType attribute ambiguity KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-97 validateAssociationStructureIntersection seems vacuous KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-121 KerML Libraries' elements shall have an elementId defined KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-124 Inherited multiplicities, semantics KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-123 Add derived property for targetFeature KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-126 Type::inheritedMemberships OCL is missing KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-157 TransitionPerformance modeling pattern more general than needed, not aligned with SysML::TransitionUsage KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-127 Add validateSubsettingTypeConformance constraint KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-159 Association end feature description missing simple example and equivalence to related types KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-205 Serious limitation of textual concrete syntax as model interchange format KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-163 Root namespaces restricted to one single file KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-206 Read only, misleading keyword, metaproperty name KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-168 Ambiguity In Directionality InOut semantics KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-197 Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-207 Annex A coverage KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-208 Composite feature values can have more than one owner KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-211 Some syntax in Core has time-dependent semantics KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-233 TimeOf::timeContinuityConstraint might be too restrictive KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-244 Semantic constraint needed for result type of a "constructor" expression KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-245 KerML should have syntax for enumerations SysML 2.0b1 KerML 1.0b2 Deferred closed
KERML-246 isDerived, semantics KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-258 Discrepancy between documentation of Collections library in spec and textual notation file KerML 1.0a1 KerML 1.0b2 Deferred closed
KERML-283 Space triggers missings KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-306 Time and space life/slice/portion modeling patterns are missing KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-308 checkFeatureParameterRedefinition fails for named-argument invocations KerML 1.0b1 KerML 1.0b2 Deferred closed
KERML-204 Behavior portions must be classified by the same behavior they are portions of KerML 1.0b1 KerML 1.0b2 Resolved closed

Issues Descriptions

Corrections to Ballot #5 resolutions

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

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

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

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

    KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations

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

    KERML_-59 OCL for checkFeatureParameterRedefinition is wrong

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

    KERML_-132 Constructor invocation expressions are semantically inconsistent

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

    Make the necessary corrections

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

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

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

    KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations

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

    KERML_-59 OCL for checkFeatureParameterRedefinition is wrong

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

    KERML_-132 Constructor invocation expressions are semantically inconsistent

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

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

    • checkConstructorExpressionResultFeatureRedefinition
    • InstantiationExpression::instantiatedType
    • OperatorExpression::instantiatedType
  • Updated: Sat, 19 Jul 2025 18:59 GMT

The term "Item" in KerML confusing against SysML

  • Key: KERML_-107
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Rename ItemFlow to Flow

    This resolution proposes the following changes:

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

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

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

    This resolution also resolves the following issue:

    • KERML_-24 Performance & Object self redefinition missing in specification document
  • Updated: Sat, 19 Jul 2025 18:59 GMT
  • Attachments:

Constructor invocation expressions are semantically inconsistent

  • Key: KERML_-132
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add ConstructorExpression

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

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

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT
  • Attachments:

Time and space life/slice/portion modeling patterns are missing

  • Key: KERML_-57
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

  • Reported: KerML 1.0b1 — Mon, 1 Jan 2024 16:02 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add the concept of variable features

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

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

    // An instance of a Vehicle is a Life by default.
    struct Vehicle {
        // This feature has a single value for the Vehicle's life.
        //  It is not a feature of its timeslices or snapshots.
        feature id : VehicleId [1];
    
        // This feature can have a different single value on each snapshot of a Vehicle.
        var mileage : Distance [1];
    }
    

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

    struct Vehicle {
        feature id : VehicleId [1];
        var mileage : Distance [1];
    
        portion parked :> timeSlices [*] {
            // When a Vehicle is parked, its mileage does not change.
            const :>> mileage;
        }
    }
    

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

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

    This resolution also resolves the following related issues:

    • KERML_-47 Read only, misleading keyword, metaproperty name
    • KERML_-154 Space and time slice descriptions are the same
    • KERML_-159 n>2-ary link ends not readonly
  • Updated: Sat, 19 Jul 2025 18:59 GMT
  • Attachments:

checkFeatureParameterRedefinition fails for named-argument invocations

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

    In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

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

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

  • Reported: KerML 1.0b1 — Mon, 8 Jan 2024 04:35 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Exclude InvocationExpressions from the constraint

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

MetadataAccessExpression::referencedElement should be derived

  • Key: KERML_-162
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Revise MetadataAccessExpression

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

isEnd of the redefining feature must match isEnd of the redefined feature

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

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

  • Reported: KerML 1.0b1 — Fri, 22 Mar 2024 19:18 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add validation constraint

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Need to revise derivation of AnnotatingElement::ownedAnnotatingRelationship

  • Key: KERML_-146
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Update the derivation

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Transitivity missing for some time/space associations

  • Key: KERML_-104
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add transitivity for time/space relations where it is missing

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

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

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

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Corrections to the resolution of KERML_-18

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

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

    1. In isCartesianProduct, the first two conditions should not be part of the first operand of the following "implies" (otherwise, e.g., a feature with no type or featuring types would incorrectly be considered a Cartesian product).
    2. In isOwnedCrossFeature, "owningType" should be "owningNamespace" (because owned cross features are required to be not owned via FeatureMemberships).
    3. In ownedCrossFeature, ownedMembers owned via FeatureValues should also be excluded from the list of ownedMemberFeatures being computed.
  • Reported: KerML 1.0b2 — Wed, 19 Feb 2025 20:25 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct operation OCL

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Typo in description of namespace

  • Key: KERML_-161
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the wording

    Agreed, this should be corrected.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Use of memberName in OwningMembership

  • Key: KERML_-165
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — KerML 1.0b4
  • Disposition Summary:

    No change

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

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Space and time slice descriptions are the same

  • Key: KERML_-154
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-57

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

n>2-ary link ends not readonly

  • Key: KERML_-159
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-57

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Corrections to the resolution of KERML_-39

  • Key: KERML_-151
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the identified problems.

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

subsets of scalarQuantities should be nonunique

  • Key: KERML_-160
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

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

    Examples:
    width, height or gaugePressure

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

  • Reported: SysML 2.0b2 — Wed, 5 Feb 2025 17:51 GMT
  • Disposition: Closed; No Change — KerML 1.0b4
  • Disposition Summary:

    Spurious issue

    This issue has been refiled with the SysML v2 FTF.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

InvocationExpression::result specialization

  • Key: KERML_-117
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add appropriate semantic constraints

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

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

  • Key: KERML_-145
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Duplicate of KERML_-117

    This is a duplicate of KERML_-117.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

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

  • Key: KERML_-144
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Covered in resolution of KERML_-117

    The resolution of KERML_-117 also resolves this issue.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

ownedParameterMember should be ownedMemberParameter

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

    typo in OCL, also on page 184

  • Reported: SysML 2.0b2 — Sat, 23 Nov 2024 10:48 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct references to ownedMemberParameter

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Confusing "Classes" with "Structures"

  • Key: KERML_-86
  • Status: closed  
  • Source: Brandenburg University of Technology ( Gerd Wagner)
  • Summary:

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

  • Reported: KerML 1.0b1 — Wed, 29 May 2024 14:58 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the text

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

two haves

  • Key: KERML_-142
  • Status: closed  
  • Source: Elparazim ( Edward Roberts)
  • Summary:

    Certain primitive data types have have specified extents of values

    two "have"s remove one

  • Reported: SysML 2.0b1 — Sun, 9 Jun 2024 17:37 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Remove redundant "have"

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Global scope notation

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

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

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

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

    Example using the global scope notation:

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

  • Reported: SysML 2.0b2 — Fri, 26 Jul 2024 11:14 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add global scope notation

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Composite feature values can have more than one owner

  • Key: KERML_-49
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    7.3.4.1 (Features Overview) says

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

    and 8.3.3.3.3 (Feature) says

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

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

  • Reported: KerML 1.0b1 — Tue, 7 Nov 2023 16:41 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-5

    The resolution of KERML_-5 also covers this issue.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

CollectExpression and SelectExpression should not reference BodyExpressionMember

  • Key: KERML_-83
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct productions

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

OCL for checkFeatureParameterRedefinition is wrong

  • Key: KERML_-59
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct OCL

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

isComposite, semantics

  • Key: KERML_-5
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 20:12 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add isComposite semantics

    This resolution adds

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

TransitionPerformance modeling pattern more general than needed, not aligned with SysML::TransitionUsage

  • Key: KERML_-41
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

    but

    • succession could subset transitionStep.transitionLink (equivalent to a binding with optional multiplicity on succession end)
    • bind succession's sourceFeature and its transitionStep.transitionLinkSource (1 to 1 end multiplicities)

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

  • Reported: KerML 1.0a1 — Fri, 25 Aug 2023 19:16 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Align TransitionPerformance modeling pattern with SysML::TransitionUsage

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

  • Updated: Sat, 19 Jul 2025 18:59 GMT

Read only, misleading keyword, metaproperty name

  • Key: KERML_-47
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Mon, 30 Oct 2023 19:10 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-57

    This resolution to KERML_-57 also resolves this issue.

  • Updated: Sat, 19 Jul 2025 18:59 GMT

validateParameterMembershipOwningType will fail for ConstructorExpressions

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

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

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

  • Reported: KerML 1.0b2 — Fri, 21 Feb 2025 04:50 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Update the constraint

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Performance & Object self redefinition missing in specification document

  • Key: KERML_-24
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 19:47 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-107

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

FeatureMembership owningType attribute ambiguity

  • Key: KERML_-35
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Mon, 10 Jul 2023 00:35 GMT
  • Disposition: Closed; No Change — KerML 1.0b4
  • Disposition Summary:

    No change

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

KerML Libraries' elements shall have an elementId defined

  • Key: KERML_-36
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

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

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

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

    Note: a similar issue will be raised on SysMLv2

  • Reported: KerML 1.0a1 — Thu, 13 Jul 2023 06:48 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Create UUID based on unique path

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

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

    The following shows some examples of element paths:

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

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Editorial errors in constraints

  • Key: KERML_-72
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the constraints

    Agreed

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Type::inheritedMemberships OCL is missing

  • Key: KERML_-39
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Sun, 30 Jul 2023 14:08 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Complete the OCL for inheritedMemberships and related operations

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

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

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

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

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

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

    This resolution also resolves the following issues:

    • KERML_-84 Type::directionOf does not handle inheritence from feature chains
    • KERML_-120 Recursive import with includeAll = true should recurse through private packages
  • Updated: Sat, 19 Jul 2025 18:58 GMT

Redundancy in association end multiplicities, ordering, and uniqueness

  • Key: KERML_-18
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:35 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Cross features owned by end features or their types

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

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

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

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

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

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

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

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

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

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

    This resolution also resolves the following related issues:

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

Navigability of AnnotatingElement<->Annotation meta-association

  • Key: KERML_-119
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Revise abstract syntax for Annotation

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

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

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

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

CheckFeatureChainExpressionResultSpecialization constraint needs to be defined

  • Key: KERML_-99
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add semantic constraint checkFeatureChainExpressionResultSpecialization

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

    So, this resolution does the following:

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

MultiplicityRanges should allow owned members other than bounds

  • Key: KERML_-140
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Update MultiplicityRange abstract syntax

    1. Update the abstract syntax for MultiplicityRange so that bound subsets ownedMember, rather than redefining it.
    2. Revise the derivation constraints for lowerBound and upperBound.
    3. Add a derivation constraint for bound.
    4. Add a validation constraint to ensure that the bound Expressions are the first ownedMembers of a MultiplicityRange.
  • Updated: Sat, 19 Jul 2025 18:58 GMT

Type::directionOf does not handle inheritence from feature chains

  • Key: KERML_-84
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-39

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

deriveExpressionResult and deriveFunctionResult should be revised

  • Key: KERML_-68
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Revise the constraints

    • Update the constraints deriveExpressionResult and deriveFunctionResult to select. ReturnParameterMemberships from featureMembership, rather than ownedFeatureMembership.
    • Also similarly update the constraints validateExpressionResultParameterMembership and validateFunctionResultParameterMembership, to ensure that an Expression or Function has at most one ResultParameterMembership, owned or inherited.
  • Updated: Sat, 19 Jul 2025 18:58 GMT

Recursive import with includeAll = true should recurse through private packages

  • Key: KERML_-120
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-39

    The resolution to KERML_-39 also resolves this issue.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Disallow public imports at root level

  • Key: KERML_-73
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Require top-level imports to be private

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Problem with the property name "targetFeature"

  • Key: KERML_-88
  • Status: closed   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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Use name "featureTarget" instead

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Add derived property for targetFeature

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

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

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

    targetFeature = if chainingFeature.isEmpty() then self else chainingFeature->last() end if
    
  • Reported: KerML 1.0b1 — Sun, 16 Jul 2023 20:19 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add derived property

    Agreed

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

Error in specification of library model UUIDs

  • Key: KERML_-115
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Revise the specification

    The specification should be revised as suggested in the issue.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Interpretation 3-tuple described as 2-tuple

  • Key: KERML_-94
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Describe interpretation as 3-tuple

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Association ends can have more than one type

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

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

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

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

  • Reported: KerML 1.0a1 — Wed, 10 May 2023 22:15 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Restrict ends to have only a single type

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

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

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

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

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Incorrect metadata example

  • Key: KERML_-121
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the example

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Problem with validateImportTopLevelVisibility constraint

  • Key: KERML_-90
  • Status: closed   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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct OCL

    Correct the OCL for validateImportTopLevelVisibility as suggested.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Interpretation function co-domain expressed incorrectly


Association end feature description missing simple example and equivalence to related types

  • Key: KERML_-42
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

    • only example of association end features is later when explaining the more advanced case of association specialization. The text references an earlier very brief description of end features in 7.3.4.2 (Feature Declaration), which points back to 7.4.5 for more information.
    • third paragraph (the one starting "An association is also a relationship between the types") describes related types, but does not mention these are same as the end feature types, as specified by the deriveAssociationRelatedType constraint in 8.3.4.4.2 (Association).

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

  • Reported: KerML 1.0b1 — Thu, 7 Sep 2023 15:33 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Nary association end multiplicity, semantics

  • Key: KERML_-20
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clauses 7.4.5 (Associations) and 8.4.4.5.1 (Associations) say

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

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

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

    • does not seem to consider instances of associated classes that do not participate in any links, because only refers to instances of links. In the Product Selection example, the cart in red on the bottom left of the first slide violates the linkedProduct "end" multiplicity 1..*, but the text above would not detect it because it does not participate in any link.
    • Applies multiplicity, ordering and uniqueness to links (last sentence), which don't have these characteristics, rather than a feature with the values of ei from all the links.
  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 15:27 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

Association end features are not necessarily consistent with corresponding features of associated classifiers

  • Key: KERML_-21
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 15:40 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Connector ends cannot give smaller lower multiplicity than their association ends

  • Key: KERML_-28
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

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

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

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

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

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

  • Reported: KerML 1.0a1 — Sun, 30 Apr 2023 15:41 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Association participant features, misleading term and textual keyword

  • Key: KERML_-16
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

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

    where Association::associationEnds identify participant features.

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

    n-aries have this form:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:09 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Context-dependent meanings for feature multiplicity, ordering, and uniqueness

  • Key: KERML_-19
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

    Clause 7.4.5 (Associations) says

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

    Clause 8.4.4.5.1 (Associations) says

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

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

    Clause 8.3.3.3.3 (Feature) says

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:47 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

Number of association end feature values, semantics

  • Key: KERML_-17
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:23 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Type union, intersection, difference semantics

  • Key: KERML_-8
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Type unioning, intersecting, and differing are described as

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

    but this semantics is not math/modeled.

  • Reported: KerML 1.0a1 — Sun, 16 Apr 2023 16:26 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add math semantics for Type union, intersection, and difference

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

End feature multiplicity textual notation

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

    Background

    Consider the flowing simple structure:

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

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

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

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

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

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

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

    1. a connection from myEngine to leftRearWheel

    2. a connection from myEngine to rightRearWheel

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

    Concern

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

    Proposal

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

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

    This would not require a change in the abstract syntax.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 23:14 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Some bindings have optional connector end multiplicities

  • Key: KERML_-13
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

    might be others.

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

  • Reported: KerML 1.0a1 — Sun, 23 Apr 2023 14:52 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b4
  • Disposition Summary:

    Merge with KERML_-18

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Make imports private by default

  • Key: KERML_-74
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Make imports private by default

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

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Restrict the functionality of recursive import

  • Key: KERML_-75
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Limit the recursion in recursive imports

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Semantic constraint needed for result type of a "constructor" expression

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

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

  • Reported: KerML 1.0b1 — Fri, 1 Dec 2023 20:59 GMT
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Add semantic constraint

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

The OCL for isFeaturedWithin is still not correct

  • Key: KERML_-70
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the OCL

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Invocation of a non-function behavior

  • Key: KERML_-67
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Allow "constructors" for Behaviors

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

relationship not defined

  • Key: KERML_-69
  • Status: closed  
  • 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
  • Disposition: Closed; No Change — KerML 1.0b4
  • Disposition Summary:

    No change

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Incorrect binding syntax in Feature Values Semantics

  • Key: KERML_-61
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct binding declarations

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

FeatureIdentificationProduction is incorrect

  • Key: KERML_-63
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Correct the production

    Agreed.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

isOrdered and isUnique are missing from the reflective abstract mapping

  • Key: KERML_-65
  • Status: closed  
  • 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
  • Disposition: Resolved — KerML 1.0b4
  • Disposition Summary:

    Fix the mapping

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Classifier multiplicity, semantics

  • Key: KERML_-2
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Dynamic multiplicity, semantics

  • Key: KERML_-3
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

isReadOnly, semantics

  • Key: KERML_-4
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

isPortion, semantics

  • Key: KERML_-6
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

isAbstract, semantics

  • Key: KERML_-7
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Abstract types (Type::isAbstract=true) are described as

    instances of this Type must also be instances of at least one of its specialized Types.

    but this semantics is not math/modeled.

  • Reported: KerML 1.0a1 — Sat, 15 Apr 2023 14:22 GMT
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

direction, semantics

  • Key: KERML_-10
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

isSufficient, semantics, expressiveness

  • Key: KERML_-9
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Steps are not always time enclosed

  • Key: KERML_-11
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Decision/MergePerformance element descriptions give incorrect modeling pattern

  • Key: KERML_-14
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Succession end multiplicity defaults not documented

  • Key: KERML_-15
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Sufficiency missing for some library types

  • Key: KERML_-22
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Conditions missing for some sufficient library types

  • Key: KERML_-23
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

XMI and JSON for model libraries

  • Key: KERML_-25
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Some types not given any semantics

  • Key: KERML_-26
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Some package-level features are mandatory

  • Key: KERML_-29
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

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

  • Key: KERML_-27
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Feature values do not specify when their expressions are evaluated

  • Key: KERML_-30
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Invariants only hold when evaluated

  • Key: KERML_-31
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Default for the first operand of a classification expression

  • Key: KERML_-33
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

validateAssociationStructureIntersection seems vacuous

  • Key: KERML_-34
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Inherited multiplicities, semantics

  • Key: KERML_-38
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Add validateSubsettingTypeConformance constraint

  • Key: KERML_-40
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Root namespaces restricted to one single file

  • Key: KERML_-43
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT
  • Attachments:

Ambiguity In Directionality InOut semantics

  • Key: KERML_-44
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

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

  • Key: KERML_-45
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Serious limitation of textual concrete syntax as model interchange format

  • Key: KERML_-46
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Annex A coverage

  • Key: KERML_-48
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

TimeOf::timeContinuityConstraint might be too restrictive

  • Key: KERML_-51
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Some syntax in Core has time-dependent semantics

  • Key: KERML_-50
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

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

  • Updated: Sat, 19 Jul 2025 18:58 GMT

KerML should have syntax for enumerations

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

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

isDerived, semantics

  • Key: KERML_-54
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

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

  • Key: KERML_-85
  • Status: closed   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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

Space triggers missings

  • Key: KERML_-56
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

TransferBefore is unsatisfiable

  • Key: KERML_-96
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:58 GMT

HappensLink disjointness documentation inconsistent

  • Key: KERML_-98
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:57 GMT

Eliminate EndFeatureMembership and ParameterMembership from abstract syntax

  • Key: KERML_-100
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:57 GMT

Incorrect succession in state and transition library

  • Key: KERML_-147
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:57 GMT
  • Attachments:

Problem with nested feature semantics

  • Key: KERML_-106
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:57 GMT

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

  • Key: KERML_-55
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b4
  • Disposition Summary:

    Defer to RTF

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future RTF.

  • Updated: Sat, 19 Jul 2025 18:57 GMT

Intersection missing for some multiple specializations

  • Key: KERML-46
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

    In Links.kerml:

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

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

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

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

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 14:35 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add intersection to some multiple specializations

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

  • Updated: Tue, 1 Jul 2025 15:02 GMT

checkConnectorTypeFeaturing is not correct

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

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

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

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

  • Reported: KerML 1.0a1 — Sat, 13 May 2023 23:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct checkConnectorTypeFeaturing constraint

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

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

  • Updated: Tue, 1 Jul 2025 15:02 GMT

Comment Locale not in textual notation

  • Key: KERML-98
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:14 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add "locale" to Comment notation

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

  • Updated: Tue, 1 Jul 2025 15:02 GMT

FlowTransferBefore needs end feature declarations

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

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

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

  • Reported: KerML 1.0b1 — Wed, 12 Jul 2023 21:35 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add end features

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Disjoining example conflicts with textual description

  • Key: KERML-110
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

    Third Paragraph

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 23:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Change the documentation on the example

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

specializesFromLibrary arguments use inconsistent notation for strings

  • Key: KERML-125
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Sun, 30 Jul 2023 13:22 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Use single quotes in OCL strings

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

LinkObject is irreflexive

  • Key: KERML-45
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Thu, 27 Apr 2023 18:58 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove disjointness of SelfSameLifeLink from Occurrence

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Measuring devices for space missing

  • Key: KERML-282
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Thu, 21 Dec 2023 17:02 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    Close

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

User-defined keywords are not allowed on metadata features

  • Key: KERML-307
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 2 Jan 2024 19:53 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Allow user-defined keywords on metadata features

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Features successors and predecessors of Occurrence should be disjoint

  • Key: KERML-234
  • Status: closed  
  • Source: Budapest University of Technology and Economics ( Dr. Vince Molnar)
  • Summary:

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

  • Reported: KerML 1.0a1 — Sat, 25 Nov 2023 11:30 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    Occurrence::successors and predecessors are (effectively) disjoint

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

     feature successors: Occurrence[0..*]
       subsets withoutOccurrences
       inverse of predecessors { ... }
    
    feature predecessors: Occurrence [0..*]
       subsets withoutOccurrences { ... }
    
    feature withoutOccurrences: Occurrence[0..*]
         unions successors, predecessors, outsideOfOccurrences
         inverse of withoutOccurrences { ...
      /* withoutOccurrences is irreflexive. */
      inv { (that as Occurrence) != (that.that as Occurrence) } }
    
  • Updated: Tue, 1 Jul 2025 15:01 GMT

package "Interactions TBD" should not be included in the XMI file

  • Key: KERML-309
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

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

  • Reported: KerML 1.0b1 — Fri, 12 Jan 2024 18:01 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove package "Interactions TBD"

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Exponentiation should be right-associative

  • Key: KERML-165
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Andrius Armonas)
  • Summary:

    If you look at the following sample:

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

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

  • Reported: KerML 1.0b1 — Thu, 14 Sep 2023 15:06 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Make exponentiation right-associative

    Exponentiation should be right-associative.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

DataType Disjointness Clarification

  • Key: KERML-174
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:22 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise the language description

    Agreed.

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Name all associations in the KerML abstract syntax

  • Key: KERML-22
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:40 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add association names

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Follow typographical conventions in the KerML Metamodel clause

  • Key: KERML-23
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:44 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update Clauses 8 and 9

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Specify default direction for the ownedParameterMember of a ParameterMembership

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

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

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

  • Reported: KerML 1.0a1 — Mon, 8 May 2023 22:31 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise the validateParameterMembershipParameterHasDirection constraint

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Reference to nonexistent class (Superclassification) in OCL rule deriveClassifierOwnedSubclassification

  • Key: KERML-259
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

    Comment indicates that this should be Subclassification

  • Reported: KerML 1.0b1 — Wed, 20 Dec 2023 10:17 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct constraint deriveClassifierOwnedSubclassification

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

OclisKindOf applied to Namespace::resolve()

  • Key: KERML-139
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

    let namespace : Element = resolve(qualification) in
    if namespace = null or not namespace.oclIsKindOf(Namespace) then null
    else namespace.oclAsType(Namespace).resolveVisible(name) endif
    
  • Reported: KerML 1.0a1 — Thu, 3 Aug 2023 14:16 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct OCL for Namespace::resolve

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Add a property for Annotations owned by an AnnotatingElement

  • Key: KERML-21
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:23 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add ownedAnnotatingRelationship property

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT
  • Attachments:

isDirected, definition, semantics

  • Key: KERML-7
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Connector::isDirected is described as

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

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

  • Reported: KerML 1.0a1 — Sat, 15 Apr 2023 14:41 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove isDirected

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Directed features inherited from a conjugated type not handled properly

  • Key: KERML-154
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Consider the following:

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

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

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

  • Reported: KerML 1.0b1 — Wed, 23 Aug 2023 17:47 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the derivation of Type::input and output

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

validateMultiplicityRangeBoundResultTypes constraint is too strong

  • Key: KERML-199
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Fri, 20 Oct 2023 13:38 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the validateMultiplicityRangeBoundResultTypes constraint

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Misspelling

  • Key: KERML-161
  • Status: closed  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    In the EBNF for MetaclassificationExpression:

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

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

    In the EBNF for IndexExpression:

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

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

  • Reported: KerML 1.0b1 — Tue, 5 Sep 2023 18:35 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct textual BNF productions

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

LinkObject disjointness is redundant

  • Key: KERML-231
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The disjointness of LinkObject in Objects.kerml

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

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

  • Reported: KerML 1.0b1 — Wed, 15 Nov 2023 15:34 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove disjointness of LinkObject

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Some readonly features are intended to have changing values

  • Key: KERML-49
  • Status: closed  
  • 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 the libraries sometimes apply it to features with values that might be intended to change over the lifetime of an instance. For example, Clause 9.2.12.2.4 (Clock) says

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

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

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

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

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 17:59 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove incorrect uses of "readonly"

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

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Remove disjointness of LinkObject

  • Key: KERML-251
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In Objects.kerml, in the declaration of LinkObject:

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

    remove disjoint from SelfLink, SelfSameLifeLink, HappensLink.

  • Reported: KerML 1.0b1 — Tue, 19 Dec 2023 19:03 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Merge with KERML-231

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Definition of property "typing" seems incomplete/inconsistent

  • Key: KERML-260
  • Status: closed  
  • Source: The MathWorks ( Mr. Alan Moore)
  • Summary:

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

  • Reported: KerML 1.0b1 — Wed, 20 Dec 2023 10:37 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    No change

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

SelfLink::thatThing does not exist in Links Model Library

  • Key: KERML-239
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 21:54 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct connector declaration

    Yes, it should be SelfLink::sameThing.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in Function Abstract Syntax Description

  • Key: KERML-249
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 3 Dec 2023 03:30 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in Function Declaration Overview

  • Key: KERML-250
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 3 Dec 2023 03:49 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

PrimaryExpressionMember production should generate a ParameterMembership

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

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

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

  • Reported: KerML 1.0a1 — Wed, 3 May 2023 17:32 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise grammar for PrimaryExpressionMember, BodyExpressionMember and FunctionReferenceExpressionMember

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Update semantic model of invariants for validateExpressionResultExpressionMembership constraint

  • Key: KERML-186
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sat, 23 Sep 2023 22:27 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the specifications of trueEvaluations and falseEvaluations

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Link Participant Plurality Typo in OCL

  • Key: KERML-237
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 21:16 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct checkFeatureEndSpecialization constraint

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

No textual syntax or derivation rules for isDirected

  • Key: KERML-238
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 21:21 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Duplicate of KERML-7

    Duplicate

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in Multiplicity Ranges Semantics

  • Key: KERML-241
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 22:01 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in Multiplicities Overview

  • Key: KERML-240
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 21:58 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typos

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in checkAssociationBinarySpecialization OCL

  • Key: KERML-242
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 22:19 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise the checkAssociationBinarySpecialization constraint

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in modelLevelEvaluable Operation text

  • Key: KERML-247
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 3 Dec 2023 02:46 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Merge with KERML-248

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Error in Expression modelLevelEvaluable operation OCL

  • Key: KERML-248
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 3 Dec 2023 02:58 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the operation Expression::modelLevelEvaluable

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Annex A (Model Execution) minor errors

  • Key: KERML-200
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

    Spelling (multiple places):

    • modelled/ing => modeled/ing
    • assocation => association
    • multiplities => multiplicities

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

    A.3.3 (One-to-one connectors)

    • second bullet list, cross reference missing, "Clause" => "A.3.2"
    • near end, in MyBikeWheel-Fork-BWF-Link, hypens => underscores

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

    • MyBasket2_BikeFork1_BBF_Link => MyBikeBasket2_Fork1_BBF_Link
    • MyBikeFork1_Basket1_BBF_Link => MyBikeBasket1_Fork1_BBF_Link
    • MyBikeFork1_Basket2_BBF_Link => MyBikeBasket2_Fork1_BBF_Link

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

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

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

    • "Instantiation step 6.b.i. the start of 6.c.i produces", insert "redefines" as a separate word between the two "feature startShot".
    • "The third of instantiation step 6.b.ii and third start of 6.c.ii produces", move "dry.dried.endShot" to just before the following semi-colon and precede it by "chains ".
    • "FeatureWritePerformances ensure when they finish that", insert "in " before "redefines onOccurrence" and "redefines replacementValues (three times each).
    • "The first of instantiation step 6.b.ii and first start of 6.c.ii produces", in "feature redefines onOccurrence", feature => in
  • Reported: KerML 1.0b1 — Fri, 20 Oct 2023 14:20 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Annex A, correct minor errors.

    Correct Annex A as indicated.

  • Updated: Tue, 1 Jul 2025 15:01 GMT
  • Attachments:

Additional problems with deriveFeatureType

  • Key: KERML-232
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    1. If a Feature is conjugated, then the validateSpecializationSpecificNotConjugated constraint prohibits the Feature from being the specific Type in either FeatureTypings or Subsettings. Nevertheless, one would expect it to have the same types as the originalType that it is conjugating (assuming that is, indeed, a Feature).
    2. The description of deriveFeatureType says that the resulting set of types has "all redundant supertypes removed". This should be interpreted to mean that any Type for which there is some conforming subtype should be removed from the set, not just that duplicates of the same Type are removed (as in the current OCL).
  • Reported: KerML 1.0b1 — Wed, 22 Nov 2023 20:40 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the deriveFeatureType constraint

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Association SourceType Cardinality Contradiction

  • Key: KERML-236
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 21 Nov 2023 21:01 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct language description

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Many mistakes and differences to implementation

  • Key: KERML-192
  • Status: closed  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Wed, 4 Oct 2023 14:03 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    Close

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

validateRedefinitionDirectionConformance does not account for conjugation

  • Key: KERML-194
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Sun, 15 Oct 2023 15:20 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise validateRedefinitionDirectionConformance constraint

    Agreed.

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Weird Concrete Syntax for ConditionalExpression

  • Key: KERML-193
  • Status: closed  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

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

    e.g. if x ? y else z

    either use symbols or words.
    Not half and half!

    if x then y else z

    OR

    if x ? y : z

  • Reported: KerML 1.0b1 — Mon, 9 Oct 2023 11:35 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    No change

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Feature Chain relationships are inconsistent with the concrete syntax

  • Key: KERML-171
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:15 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add conjugation to the list

    Agreed, conjugation should be added to the list.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

ClassifierDeclaration concrete syntax typo

  • Key: KERML-172
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:17 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct production ClassifierDeclaration

    It is, indeed, supposed to be TypeRelationshipPart.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Classifier Description Typo

  • Key: KERML-173
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:18 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

checkAssociationStructureSpecialization invalid reference

  • Key: KERML-179
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:35 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct OCL

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

non-terminal does not exist in the specification

  • Key: KERML-189
  • Status: closed  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

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

  • Reported: KerML 1.0b1 — Wed, 4 Oct 2023 12:21 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Replace MetaclassificationOperator production

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Model Interchange Overview Typo

  • Key: KERML-181
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:37 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Comment textual syntax defined differently to implementation

  • Key: KERML-191
  • Status: closed  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

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

    Comment is defined in the document as

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

    and in the implementation as

    Comment returns SysML::Comment :
    	( 'comment' Identification?  ('about'  Annotation  ( ',' Annotation )* )?  )?
    	REGULAR_COMMENT
    ;
    
  • Reported: KerML 1.0b1 — Wed, 4 Oct 2023 14:00 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the Comment production

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

OwnedExpression missing ConditionalBinaryOperatorExpression

  • Key: KERML-190
  • Status: closed  
  • Source: itemis AG ( Dr. David Akehurst)
  • Summary:

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

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

       OwnedExpression
            = ConditionalExpression
            | BinaryOperatorExpression
            | UnaryOperatorExpression
            | ClassificationExpression
            | MetaclassificationExpression
            | ExtentExpression
            | PrimaryExpression
        ;
    
  • Reported: KerML 1.0b1 — Wed, 4 Oct 2023 13:57 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct OwnedExpression production

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

FeatureDeclaration ConjugationPart lexical element incorrect reference

  • Key: KERML-114
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

    Proposed Text:

    FeatureDeclaration : Feature =
    ( isSufficient ?= 'all' )?
    ( FeatureIdentification
    ( FeatureSpecializationPart | ConjugationPart )?
    | FeatureSpecializationPart
    | ConjugationPart
    )
    FeatureRelationshipPart*
    
  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 23:42 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the production FeatureDeclaration

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Misidentified non-terminals and misspelled non-terminals in the EBNF

  • Key: KERML-162
  • Status: closed   Implementation work Blocked
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:
    MetaclassificationExpression : OperatorExpression =
    ownedRelationship += MetadataArgumentMember
    ( operator = MetaClassificationTestOperator
    ownedRelationship += TypeReferenceMember
    | operator = MetaCastOperator
    owendRelationsip += TypeResultMember
    )
    

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

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

  • Reported: KerML 1.0b1 — Tue, 5 Sep 2023 18:56 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Duplicate of KERML-189

    Duplicates KERML-189,

  • Updated: Tue, 1 Jul 2025 15:01 GMT

unknown non-terminal reference in EBNF

  • Key: KERML-160
  • Status: closed   Implementation work Blocked
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

    In the EBNF:

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

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

  • Reported: KerML 1.0b1 — Tue, 5 Sep 2023 19:05 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Merge with KERML-189

    This is handled in the resolution to KERML-189.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

No production for nonterminal

  • Key: KERML-164
  • Status: closed  
  • Source: Georgia Institute of Technology ( Dr. Richard Wallace)
  • Summary:

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

    FeatureDeclaration : Feature =
    ( isSufficient ?= 'all' )?
    ( FeatureIdentification
    ( FeatureSpecializationPart | ConjugationPart )?
    | FeatureSpecializationPart
    | FeatureConjugationPart
    )
    FeatureRelationshipPart*
    
  • Reported: KerML 1.0b1 — Thu, 14 Sep 2023 01:33 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Duplicate of KERML-114

    Duplicates KERML-114.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Typo in Conjugation Description

  • Key: KERML-167
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 17:49 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

checkFeatureSubobjectSpecialization incorrect Font

  • Key: KERML-170
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct formatting

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Feature isDerived metaproperty Typo

  • Key: KERML-169
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:09 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Protected membership inheritance through Specialization type

  • Key: KERML-106
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 21:53 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Textual Syntax allows multiple ConjugationParts on a Type

  • Key: KERML-109
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:
    TypeDeclaration : Type =
    ( isSufficient ?= 'all' )? Identification
    ( ownedRelationship += OwnedMultiplicity )?
    ( SpecializationPart | ConjugationPart )+
    TypeRelationshipPart*
    

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 22:13 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct TypeDeclaration production

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Conjugation Textual Redundant Word

  • Key: KERML-108
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 22:06 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Disjoining textual notation typo on disjoiningType

  • Key: KERML-111
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

    Disjoining =
    ( 'disjoining' Identification )?
    'disjoint'
    ( typeDisjoined = [QualifiedName]
    | typeDisjoined = FeatureChain
    { ownedRelatedElement += typeDisjoined }
    )
    'from'
    ( disjoiningType = [QualifiedName]
    | disjoinginType = FeatureChain
    { ownedRelatedElement += disjoiningType }
    )
    RelationshipBody
    
    OwnedDisjoining : Disjoining =
    disjoiningType = [QualifiedName]
    | disjoinginType = FeatureChain
    { ownedRelatedElement += disjoiningType }
    
  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 23:27 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct textual BNF productions

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

oclAsType applied to resolveGlobal

  • Key: KERML-138
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The signature of resolveGlobal is

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

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

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

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

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

    I gather a memberElement navigation is needed, as in

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

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

  • Reported: KerML 1.0b1 — Thu, 3 Aug 2023 14:09 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct uses of resolveGlobal

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

    1. validateSubsettingFeaturingTypes
    2. checkOperatorExpressionSpecialization
    3. checkFeatureValueBindingConnector
    4. checkMetadataFeatureSemanticSpecialization
  • Updated: Tue, 1 Jul 2025 15:01 GMT

Expression::result has an incorrect subsetting

  • Key: KERML-155
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

  • Reported: API4KP 1.0b2 — Thu, 24 Aug 2023 03:01 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Fix XMI

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

InsideOf association end feature redefines cross feature

  • Key: KERML-158
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Tue, 5 Sep 2023 18:00 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct InsideOf::smallerSpace

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Subsetting::/owningType is mandatory

  • Key: KERML-54
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

    • Subsetting::/owningFeature:Feature[1] narrows the multiplicity inherited from Type::/owningType[0..1] in Clause 8.3.3.1.1 (Overview, Types Abstract Syntax), Figure 10 (Specialization).
    • Redefinition::/owningFeature:Feature[0..1] subsets the above with the same name, which is not allowed, and widens the multiplicity back to the one on Type.

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

  • Reported: KerML 1.0a1 — Sun, 30 Apr 2023 14:41 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct multiplicity of Subsetting::owningFeature

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT
  • Attachments:

Occurrences do not identify local spatial frame

  • Key: KERML-62
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Wed, 3 May 2023 17:54 GMT
  • Disposition: Closed; No Change — KerML 1.0b2
  • Disposition Summary:

    No change

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

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

The MetadataFeature::metaclass multiplicity is too restrictive

  • Key: KERML-90
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

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

    And this violates the multiplicity of MetadataFeature::metaclass.

  • Reported: KerML 1.0a1 — Tue, 13 Jun 2023 17:48 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Change MetadataFeature::metaclass from a redefinition to a subset

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Car necessary and sufficiency example

  • Key: KERML-105
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 21:48 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Type Membership Multiplicity text conflict

  • Key: KERML-104
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 21:23 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct text

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Link participant feature called an association end

  • Key: KERML-39
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.2.3.1 (Links Overview) says

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

    but the two places it appears in the Links model library

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 15:24 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Link::participant generalizes association ends

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Universal features can have many values

  • Key: KERML-56
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

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

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

    By default this is the singleton universalClock.

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

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

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

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

  • Reported: KerML 1.0a1 — Mon, 1 May 2023 13:52 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Model "universal" features as "individuals"

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Spatial links can be occurrences

  • Key: KERML-44
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

    but

    • Some links can be occurrences without being link objects (LinkObject specializes of Link and Object, but does not intersect them).
    • Spatial links are not disjoint with LinkObject or Occurrence in the libraries.
  • Reported: KerML 1.0a1 — Thu, 27 Apr 2023 18:44 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add SpaceLink, disjoint from Occurrence

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

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

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

    This is reported in KERML-46

  • Updated: Tue, 1 Jul 2025 15:01 GMT

KerML 7.4.7.2 Behavior Declaration: last example

  • Key: KERML-59
  • Status: closed  
  • Source: ProSTEP iViP Association ( Mr. Bertil Muth)
  • Summary:

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

    binding picture = focus.picture;

    I assume this should be

    binding picture = shoot.picture;

    in order to be consistent with the declaration before.

  • Reported: KerML 1.0a1 — Wed, 3 May 2023 07:03 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct example

    Correct as proposed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Connector declaration does not allow a feature value

  • Key: KERML-24
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The second line of the following does not parse:

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

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

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

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

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

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

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

    ItemFlowDeclaration : ItemFlow =
        ( FeatureDeclaration ValuePart?
          ( 'of' ownedRelationship += ItemFeatureMember )?
          ( 'from' ownedRelationship += ItemFlowEndMember
            'to' ownedRelationship += ItemFlowEndMember )?
        | ( isSufficient ?= 'all' )?
          ownedRelationship += ItemFlowEndMember 'to'
          ownedRelationship += ItemFlowEndMember
    
  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:53 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct textual notation for Connectors

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

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Performances can be objects, behaviors can be structures

  • Key: KERML-43
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 9.2.5.1 (Objects Overview) says

    Objects and Performances do not overlap

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

    Clause 7.4.4 (Structures) says

    Structures and behaviors do not overlap,

    but there is no constraint for this.

  • Reported: KerML 1.0a1 — Thu, 27 Apr 2023 18:04 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Make Object and Performance disjoint

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Reflective KerML abstract syntax model has inconsistencies

  • Key: KERML-25
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:56 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Regenerate the KerML.kerml model file

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Anything.self subsetting Inconsistent declaration with Base.kerml declaration

  • Key: KERML-178
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

    Features
    self : Anything

    {subsets selfSameLife}

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:33 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update documentation

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Wrong documentation format for class Occurrence in Semantic Library

  • Key: KERML-198
  • Status: closed  
  • Source: DEKonsult ( Mr. Hans Peter de Koning)
  • Summary:

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

  • Reported: KerML 1.0b1 — Fri, 20 Oct 2023 09:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct documentation

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Update Kernel Semantic Library for validateRedefinitionDirectionConformance constraint

  • Key: KERML-182
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    1. Occurrences::ObserveChange::transfer::source::sourceOutput should have direction out.
    2. TransitionPerformances::TransitionPerformance::accept should have direction in.
  • Reported: KerML 1.0b1 — Sat, 23 Sep 2023 20:56 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the library models as necessary

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Documentation of features in Transfers library model is wrong

  • Key: KERML-227
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Mon, 13 Nov 2023 18:48 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update library model specification

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Validation constraints are missing in the KerML abstract syntax

  • Key: KERML-20
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    8.3.3.1.10 Type

    validateTypeOwnedUnioningNotOne – A Type must not have exactly one ownedUnioning.

    validateTypeOwnedIntersectingNotOne – A Type must not have exactly one ownedIntersecting.

    validateTypeOwnedDifferencingNotOne – A Type must not have exactly one ownedDifferencing.

    8.3.3.3.3 Feature

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

    8.3.3.3.8 Redefinition

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

    8.3.3.3.10 Subsetting

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

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

    8.3.4.5.2 BindingConnector

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

    8.3.4.5.3 Connector

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

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

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

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

    8.3.4.8.3 FeatureChainExpression

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

    8.3.4.8.4 FeatureReferenceExpression

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

    8.3.4.8.5 InvocationExpression

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

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

    8.3.4.8.14 OperatorExpression

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

    8.3.4.8.15 SelectExpression

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

    8.3.4.10.2 FeatureValue

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

    8.3.4.12.3 MetadataFeature

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

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

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

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 22:17 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add missing constraints

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

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

Occurrences can be data values

  • Key: KERML-42
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    7.4.1 (Kernel Overview) says

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

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

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

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

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

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

  • Reported: KerML 1.0a1 — Thu, 27 Apr 2023 16:03 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Make Occurrence::Occurrence disjoint from Base::DataValue

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Update Kernel Model Libraries for validateFeatureValueOverriding constraint

  • Key: KERML-184
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

    Update the library models as necessary

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

DataFunctions::Min and Max should not be capitalized

  • Key: KERML-188
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 3 Oct 2023 12:05 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Make the names lowercase

    Agreed that the names should be lowercase-initial.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Transfer sourceOutput and targetInput directions

  • Key: KERML-195
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 15 Oct 2023 16:44 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove directions from sourceOutput and targetInput

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Problems with IfThenElsePerformance

  • Key: KERML-77
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Thu, 11 May 2023 03:23 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise IfThenElsePerformance

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

  • Updated: Tue, 1 Jul 2025 15:01 GMT

BaseFunctions::',' has a bad parameter declaration

  • Key: KERML-88
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the Kernel Function Library model BaseFunctions, in the declaration of the ',' function, the seq2 feature is supposed to be the second input parameter, but it is missing an in direction keyword.

  • Reported: KerML 1.0a1 — Sun, 4 Jun 2023 11:28 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add missing "in" keyword

    Add the missing keyword.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Binary association ends always unique

  • Key: KERML-38
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    In the Links model library, BinaryLink::source/target are defined as

    assoc all BinaryLink specializes Link {
     feature participant: Anything[2] nonunique ordered redefines Link::participant;
     readonly end feature source: Anything[0..*] subsets participant;
     readonly end feature target: Anything[0..*] subsets participant; }
    

    making source/target unique by default (subsets don't inherit ordering/uniqueness). This prevents modelers from defining the corresponding features of associated classifiers as nonunique (see KERML-37), because nonunique is less restrictive than unique.

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 15:19 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    BinaryLink::source/target nonunique

    Add nonunique keyword to BinaryLink::source/target in Links.kerml.

  • Updated: Tue, 1 Jul 2025 15:01 GMT

Natural unnecessary explicit general type declaration

  • Key: KERML-175
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:24 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Remove specialization of DataValue

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Base Overview Typo

  • Key: KERML-176
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:26 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Legacy, so incorrect, wording in Anything Description

  • Key: KERML-177
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:28 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct sentence

    Agreed that the sentence needs to be corrected. The proposed wording is slightly different than what is suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Occurrences Overview Typo

  • Key: KERML-180
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 18:36 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveFeatureType is not correct

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

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

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

  • Reported: KerML 1.0b1 — Fri, 4 Aug 2023 20:07 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct description and OCL for deriveFeatureType

    The description of the constraint is revised to be consistent with the OCL, and the OCL is revised to handle circular subsetting relationships.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveTypeOwned TypeRelationship constraints have incomplete OCL

  • Key: KERML-112
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 23:31 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct OCL

    Agreed. In addition, the OCL for deriveTypeOwnedConjugator has the same problem.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveTypeFeatureMembership incorrect unioning

  • Key: KERML-117
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Mon, 10 Jul 2023 00:57 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the OCL for deriveTypeFeatureMembership

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveFeatureFeaturingType conflicts with owningType

  • Key: KERML-118
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Mon, 10 Jul 2023 01:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the OCL for deriveFeatureFeaturingType

    The OCL for deriveFeatureFeaturingType should use featuring rather than typeFeaturing. The property typeFeaturing contains only the TypeFeaturings for which a Feature is the featureWithType, while featuring contains all Featurings relating to a Feature, including all FeatureMemberships (which are Featurings).

    Note also that Feature::owningType is derived implicitly as the inverse of Type::feature, for which the derivation is given by deriveTypeFeature.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateClassSpecialization is too strict

  • Key: KERML-122
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The documentation for the constraint validateClassSpecializtion states:

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

    with the OCL

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

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

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

  • Reported: KerML 1.0b1 — Wed, 12 Jul 2023 20:29 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise OCL for validateClassSpecification

    The requested loosening of the validateClassSpecialization constraint can be best achieved by simply changing the check in the OCL for not oclIsKindOf(AssociationStructure) to not oclIsKindOf(Association). This will permit both AssociationStructures and Interactions (both of which are kinds of Class and kinds of Association) to specialize Associations, as desired. However, while currently AssociationStructures and Interactions are the only two kinds of Class that are also Associations, the proposed updated OCL would also allow for the possibility of a future extension to the abstract syntax adding another such metaclass, without having to further update this OCL.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

OCL errors in validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf

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

    In the constraints validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf, the name chainingFeatures should be chainingFeature. Also, validateFeatureChainingFeatureNotOne needs documentation.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:16 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the identified validation constraints

    The identified constraints are corrected as suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Semantic constraints for subtypes of LiteralExpression are missing

  • Key: KERML-18
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The Kernel Semantic Library model Performances includes features corresponding to each of the various kinds of LiteralExpression (e.g., literalBooleanEvaluations for LiteralBoolan, literalStringEvaluations for LiteralString, etc.; see KerML specification, 9.2.6.2). However, semantic constraints requiring the LiteralExpressions subclasses to specialize these features are missing in the abstract syntax (see KerML, 8.3.4.8). Adding these constraints would also allow the checkFeatureResultSpecialization constraint (see KerML, 8.3.3.3.3) to be simplified by removing the requirement that “If a Feature has an owningType that is a LiteralExpression it must directly or indirectly specialize the DataType from the ScalarValues package in the Kernel Data Types Library corresponding to the kind of LiteralExpression.” (since this would be automatically satisfied by the implied specializations for each kind of LiteralExpression and the {{checkFeatureResultSpecialization} constraint).

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:34 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add semantic constraints for literal expressions

    Add the suggested semantic constraints.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Namespace Description Textual Errors

  • Key: KERML-100
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:29 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct description

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveMembershipMemberElementId text elementId typo

  • Key: KERML-99
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:17 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct constraint description.

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

OwningMembership Description ownedMemberElement typo

  • Key: KERML-102
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

    "The ownedMemberElement becomes an ownedMember of the membershipOwningNamespace."

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:41 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct description

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateSpecificationSpecificNotConjugated Typo and over Constraint

  • Key: KERML-107
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 22:02 GMT
  • Disposition: Duplicate or Merged — KerML 1.0b2
  • Disposition Summary:

    Merge with KERML-96

    The editorial issue has already been reported in KERML-96.

    On the more serious point, it was decided during the language design of the conjugation relationship that it would be semantically cleanest not to mix conjugation and specialization. Conjugated types are intended to provide an essentially syntactic simplification for matching inputs and outputs across connectors, not to introduce a different classification hierarchy from that modeled with the non-conjugated original types.

    So, the intent is specifically that a conjugated type not specialize any conjugated types of its original types. Conjugation happens independently at each level of the a classification hierarchy, as desired by the modeler.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveElementIsLibraryElement Typo

  • Key: KERML-103
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:43 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update OCL

    The OCL syntax does not actually require spaces around the <>. Stylistically, however, it is more consistent to add the space, as suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

deriveFeatureOwnedSubsetting text references wrong attribute

  • Key: KERML-113
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 23:37 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct description of deriveFeatureOwnedSubsetting

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateSpecializationSpecificNotConjugated documentation is wrong

  • Key: KERML-96
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 11 Jul 2023 04:14 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update validateSpecializationSpecificNotConjugated description

    Update the constraint description as suggested. In addition, put all metaclass names in code font.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

FeatureMembership Description Typo

  • Key: KERML-115
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Mon, 10 Jul 2023 00:23 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the description of FeatureMembership

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

OCL errors in specialization constraints

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

    There are errors in the OCL for the following specialization constraints:

    8.3.3.3.3 Feature

    checkFeatureDataValueSpecialization and checkFeatureObjectSpecializationspecializesFromLibary should be specializesFromLibrary

    8.3.4.6.3 Step

    checkStepSpecialization – Should use specializesFromLibrary

  • Reported: KerML 1.0a1 — Fri, 19 May 2023 21:01 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the specialization constraints

    Correct the identified constraints as suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

The checkFeatureValuationSpecialization constraint is incorrect

  • Key: KERML-89
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In subclause 8.4.4.11 Feature Values Semantics, it states that

    The checkFeatureValuationSpecialization constraint requires that, if the featureWithValue has no explicit ownedSpecializations and is not directed, then it subsets the result parameter of the value Expression.

    However, the specification of checkFeatureValuationSpecialization in subclause 8.3.3.3.3 only requires

    If a Feature has a FeatureValue, then it must specialize the result of the value Expression of the FeatureValue.

    without the limitation that "the featureWithValue has no explicit ownedSpecializations and is not directed" (and the OCL is consistent with the textual description of the constraint).

  • Reported: KerML 1.0a1 — Sun, 11 Jun 2023 22:18 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the checkFeatureValuationSpecialization constraint

    As discussed in 8.4.4.11 Feature Values Semantics, if a Feature is directed or has ownedSpecializations, it is desirable not to have it implicitly specialize the result of the value Expression, but, rather, to have it's type checked against the type of the result. Therefore, the checkFeatureValueSpecialization constraint should be updated to reflect the description in 8.4.4.11.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

The description of deriveFeatureReferenceExpressionReferent is wrong

  • Key: KERML-94
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.4.8.4 FeatureReferenceExpression, the description of deriveFeatureReferenceExpressionReferent is

    The targetFeature of a FeatureChainExpression is the memberElement of its first ownedMembership that is not a ParameterMembership.

    This description should, instead, start "The referent of a FeatureReferenceExpression is the..."

  • Reported: KerML 1.0a1 — Mon, 3 Jul 2023 23:06 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct deriveFeatureReferenceExpressionReferent description

    Correct the constraint description as suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

NamespaceImport Description Incorrect

  • Key: KERML-101
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

    So it should read:

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

  • Reported: KerML 1.0b1 — Sun, 9 Jul 2023 20:37 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct description

    Agreed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

The checkFeatureEndSpecialization constraint should apply to Connectors as well as Associations

  • Key: KERML-19
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The checkFeatureEndSpecialization semantic constraint requires that

    If a Feature has isEnd = true and an owningType that is an Association, then it must directly or indirectly specialize Links::Link::participants from the Kernel Semantic Library.

    If a Connector is explicitly typed by one or more Associations, then it’s ends will redefine the corresponding Association ends and will thus also indirectly specialize Link::participants. However, if the Connector adds additional ends, then these will not redefine any Association ends and there is currently no requirement that these ends specialize Link::participants. In particular, the base Association Link has no ends, so when an n-ary Connector is implicitly typed by it, none of its ends will redefine Association ends, and so none of them will subset participants, which is semantically incorrect.

    The checkFeatureEndSpecialization constraint needs to be updated to also cover such cases.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:40 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Update the checkFeatureEndSpecialization constraint

    Update the constraint as suggested.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateTypeAtMostOneConjugator OCL is wrong

  • Key: KERML-95
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

    Also, the constraint has no documentation.

  • Reported: KerML 1.0b1 — Tue, 11 Jul 2023 04:07 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct validateTypeAtMostOneConjugator

    Correct the constraint as suggested and document it.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

7.4.1 Kernel Overview: Occurence instead of Object superclass

  • Key: KERML-60
  • Status: closed  
  • Source: ProSTEP iViP Association ( Mr. Bertil Muth)
  • Summary:

    In clause 7.4.1 Kernel Overview, there is the following sentence:
    "For example, classes must directly or indirectly subclassify the library class Object"

    I assume the superclass mentioned should be Occurence, not Object.

  • Reported: KerML 1.0a1 — Wed, 3 May 2023 07:11 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct reference and other typos

    The superclass mentioned should indeed be Occurrence, not Object. There are also some other typos in the same paragraph.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Some Feature constraints have no description

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

    The following constraints of Feature have no descriptions in the abstract syntax:

    • deriveFeatureFeaturingType
    • validateFeatureChainingFeatureNotOne
  • Reported: KerML 1.0a1 — Thu, 11 May 2023 03:31 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add descriptions

    Add descriptions for the constraints.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Typo in 7.4.7.2

  • Key: KERML-64
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 7.4.7.2 Behavior Declaration, in the sixth paragraph (before the "behavior Focus" example), in the last sentence, "superclassifer" should be "superclassifier".

  • Reported: KerML 1.0a1 — Fri, 5 May 2023 21:00 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Correct as proposed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Incorrect OCL for validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf

  • Key: KERML-80
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the OCL for the Feature constraints validateFeatureChainingFeatureNotOne and validateFeatureChainingFeaturesNotSelf in the abstract syntax, the references to chainingFeatures (plural) should be chainingFeature (singular).

  • Reported: KerML 1.0a1 — Thu, 11 May 2023 03:44 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct OCL

    Correct the OCL.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateRedefinitionFeaturingTypes documentation and constraint are wrong

  • Key: KERML-13
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The documentation for validateRedefinitionFeaturingTypes should state that it applies to Redefinition, not Subsetting. The documentation and OCL constraint should also use redefinedFeature and redefiningFeature, rather than subsettedFeature and subsettingFeature.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:19 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct validateRedefinitionFeaturingTypes

    Correct the constraint as suggested. In addition, the call to resolveGlobal in the OCL needs to be followed by a navigation to memberElement.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

The OCL for checkFeatureEndRedefinition is wrong

  • Key: KERML-17
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The documentation for the checkFeatureEndRedefinition constraint is

    If a Feature has isEnd = true and an owningType that is not empty, then, for each direct supertype of its owningType, it must redefine the endFeature at the same position, if any.

    However, the OCL for the constraint requires the redefinitions to be of owned endFeatures of the supertypes, which is inconsistent with the constraint documentation, and is also inconsistent with the discussion in Language Description subclauses for Associations and Connectors (7.4.5 and 7.4.6) and with the corresponding Semantics subclauses (8.4.4.5 and 8.4.4.6).

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:30 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct the OCL for checkFeatureEndRedefinition

    Correct the OCL as suggested. Also correct the computation of the index i, and use the ownedEndFeature and endFeature properties that already exist for Type.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Typo in Grammar

  • Key: KERML-31
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    Clause 8.2.5.7.1
    The closing apostrophe at the end of line is missing:

    FunctionBody : Type =
    ';' | '{' FunctionBodyPart '}

    Also, in the list of reserved words, "assign" is reserved, but doesn't appear in any KerML grammar. (It is a SysML v2 keyword, though).

  • Reported: KerML 1.0a1 — Sat, 22 Apr 2023 00:42 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct production and reserved word list

    Correct the FunctionBody production as proposed and remove assign from the reserved word list.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Typo in description of Connector::targetFeature

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

    In 8.3.4.5.3 Connector, in the description of targetFeature, the "p>" at the beginning of the paragraph should be deleted.

  • Reported: KerML 1.0a1 — Fri, 5 May 2023 21:02 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct typo

    Correct as proposed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateItemFlowItemFeature documentation is wrong

  • Key: KERML-14
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The current documentation for validateItemFlowItemFeature is

    An ItemFlow must have at most one ownedFeature that is an ItemFlow.

    It should be “…that is an ItemFeature.”

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:22 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct constraint description

    Correct the constraint description as proposed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Rename validateDatatypeSpecialization to validateDataTypeSpecialization

  • Key: KERML-16
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraint validateDatatypeSpecialization should be named validateDataTypeSpecialization, because the metaclass is named DataType, not Datatype.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:26 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct constraint name

    Correct the constraint name as proposed.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Names validatePackageFilterIsBoolean and validatePackageFilterIsModelEvaluable are wrong

  • Key: KERML-15
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The constraints validatePackageFilterIsBoolean and validatePackageFilterIsModelLevelEvaluable are owned by ElementFilterMembership and apply to its condition property. Therefore, they should be named validateElementFilterMembershipConditionIsBoolean and validateElementFilterMembershipConditionIsModelLevelEvaluable.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 21:25 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Correct constraint names

    Correct the constraint names as proposed

  • Updated: Tue, 1 Jul 2025 15:00 GMT

List of symbols incomplete

  • Key: KERML-30
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    The list of symbols shown in Clause 8.2.2.7 lacks several symbols. The symbols missing are ".", ".?", "===" and "!==".

  • Reported: KerML 1.0a1 — Sat, 22 Apr 2023 00:16 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Add missing symbols

    Add the missing symbols.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Validation constraints are missing in the SysML abstract syntax

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

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

    8.3.17.2 ExhibitStateUsage

    1. validateExhibitStateUsageReference – If an ExhibitStateUsage has an ownedReferenceSubsetting, then its referencedFeature must be a StateActionUsage.

    8.3.19.2 AssertConstraintUsage

    2. validateAssertConstraintUsageReference – If an AssertConstraintUsage has an ownedReferenceSubsetting, then its referencedFeature must be a ConstraintUsage.

    8.3.20.10 SatisfyRequirementUsage

    4. validateSatisfyRequirementUsageReference – If a SatisfyRequirementUsage has an ownedReferenceSubsetting, then its referencedFeature must be a RequirementUsage.

    8.3.24.2 IncludeUseCaseUsage

    5. validateIncludeUseCaseUsageReference – If an IncludeUseCaseUsage has an ownedReferenceSubsetting, then its referencedFeature must be a UseCaseUsage.

  • Reported: KerML 1.0a1 — Tue, 25 Apr 2023 20:48 GMT
  • Disposition: Transfered — KerML 1.0b2
  • Disposition Summary:

    Transferred to SysML v2 FTF

    This issue was created under the KerML FTF by mistake. It has been transferred to the SysML v2 FTF (SYSML2-28).

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Classifier multiplicity, semantics

  • Key: KERML-1
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Dynamic multiplicity, semantics

  • Key: KERML-2
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

isComposite, semantics

  • Key: KERML-4
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 20:12 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

isReadOnly, semantics

  • Key: KERML-3
  • Status: closed  
  • 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.

  • Reported: KerML 1.0a1 — Thu, 13 Apr 2023 20:02 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

isPortion, semantics

  • Key: KERML-5
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

isAbstract, semantics

  • Key: KERML-6
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Abstract types (Type::isAbstract=true) are described as

    instances of this Type must also be instances of at least one of its specialized Types.

    but this semantics is not math/modeled.

  • Reported: KerML 1.0a1 — Sat, 15 Apr 2023 14:22 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Type union, intersection, difference semantics

  • Key: KERML-8
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Type unioning, intersecting, and differing are described as

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

    but this semantics is not math/modeled.

  • Reported: KerML 1.0a1 — Sun, 16 Apr 2023 16:26 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

isSufficient, semantics, expressiveness

  • Key: KERML-9
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Steps are not always time enclosed

  • Key: KERML-11
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

direction, semantics

  • Key: KERML-10
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT
  • Attachments:

End feature multiplicity textual notation

  • Key: KERML-26
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Background

    Consider the flowing simple structure:

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

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

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

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

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

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

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

    1. a connection from myEngine to leftRearWheel

    2. a connection from myEngine to rightRearWheel

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

    Concern

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

    Proposal

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

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

    This would not require a change in the abstract syntax.

  • Reported: KerML 1.0a1 — Fri, 21 Apr 2023 23:14 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Some bindings have optional connector end multiplicities

  • Key: KERML-27
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

    might be others.

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

  • Reported: KerML 1.0a1 — Sun, 23 Apr 2023 14:52 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Decision/MergePerformance element descriptions give incorrect modeling pattern

  • Key: KERML-28
  • Status: closed  
  • 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. 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 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Succession end multiplicity defaults not documented

  • Key: KERML-29
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Association participant features, misleading term and textual keyword

  • Key: KERML-34
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

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

    where Association::associationEnds identify participant features.

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

    n-aries have this form:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:09 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Number of association end feature values, semantics

  • Key: KERML-35
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:23 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Redundancy in association end multiplicities, ordering, and uniqueness

  • Key: KERML-36
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:35 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT
  • Attachments:

Context-dependent meanings for feature multiplicity, ordering, and uniqueness

  • Key: KERML-37
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

    Clause 7.4.5 (Associations) says

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

    Clause 8.4.4.5.1 (Associations) says

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

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

    Clause 8.3.3.3.3 (Feature) says

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 14:47 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT
  • Attachments:

Nary association end multiplicity, semantics

  • Key: KERML-40
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clauses 7.4.5 (Associations) and 8.4.4.5.1 (Associations) say

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

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

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

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

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT
  • Attachments:

Association end features are not necessarily consistent with corresponding features of associated classifiers

  • Key: KERML-41
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0a1 — Wed, 26 Apr 2023 15:40 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Sufficiency missing for some library types

  • Key: KERML-47
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Conditions missing for some sufficient library types

  • Key: KERML-48
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Performance & Object self redefinition missing in specification document

  • Key: KERML-50
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Fri, 28 Apr 2023 19:47 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

XMI and JSON for model libraries

  • Key: KERML-51
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Connector ends cannot give smaller lower multiplicity than their association ends

  • Key: KERML-55
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

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

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

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

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

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

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

  • Reported: KerML 1.0a1 — Sun, 30 Apr 2023 15:41 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Some types not given any semantics

  • Key: KERML-52
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Some package-level features are mandatory

  • Key: KERML-57
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    The features universalClock, defaultMonitor and defaultFrame are intended to be single values that are universally available (see also resolution KERML-214 to issue KERML-56). The feature earlierFirstIncomingTransferSort has multiplicity [0..*] by default. It is used as the default for the feature Occurrence::incomingTransferSort, which also has multiplicity [0..*], so the multiplicity is appropriate.

    The problem, though, is that they are not actually single values that are universally available, but features of Anything, which means that every instance in the Universe will have their own copy. There does not seem to be anything that would force the values of different instances of these features to be the same.

    However, due to lack of time, the FTF is deferring further consideration of this issue to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 15:00 GMT

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

  • Key: KERML-53
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Feature values do not specify when their expressions are evaluated

  • Key: KERML-58
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Invariants only hold when evaluated

  • Key: KERML-63
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Association ends can have more than one type

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

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

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

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

  • Reported: KerML 1.0a1 — Wed, 10 May 2023 22:15 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Default for the first operand of a classification expression

  • Key: KERML-93
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

FeatureMembership owningType attribute ambiguity

  • Key: KERML-116
  • Status: closed  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Mon, 10 Jul 2023 00:35 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

validateAssociationStructureIntersection seems vacuous

  • Key: KERML-97
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

KerML Libraries' elements shall have an elementId defined

  • Key: KERML-121
  • Status: closed  
  • Source: Airbus Group ( Mr. Yves Bernard)
  • Summary:

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

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

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

    Note: a similar issue will be raised on SysMLv2

  • Reported: KerML 1.0a1 — Thu, 13 Jul 2023 06:48 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Inherited multiplicities, semantics

  • Key: KERML-124
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Add derived property for targetFeature

  • Key: KERML-123
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

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

    targetFeature = if chainingFeature.isEmpty() then self else chainingFeature->last() end if
    
  • Reported: KerML 1.0b1 — Sun, 16 Jul 2023 20:19 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Type::inheritedMemberships OCL is missing

  • Key: KERML-126
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0a1 — Sun, 30 Jul 2023 14:08 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

TransitionPerformance modeling pattern more general than needed, not aligned with SysML::TransitionUsage

  • Key: KERML-157
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

    but

    • succession could subset transitionStep.transitionLink (equivalent to a binding with optional multiplicity on succession end)
    • bind succession's sourceFeature and its transitionStep.transitionLinkSource (1 to 1 end multiplicities)

    giving the desired result without introducing new associations for each transitionStep. This would also align it with SysML's modeling pattern specified in TransitionUsage::checkTransitionUsageSuccessionBindingConnector and checkTransitionUsageSourceBindingConnector (after the latter is corrected as proposed in SYSML2-397).

  • Reported: KerML 1.0a1 — Fri, 25 Aug 2023 19:16 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Add validateSubsettingTypeConformance constraint

  • Key: KERML-127
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Association end feature description missing simple example and equivalence to related types

  • Key: KERML-159
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

    • only example of association end features is later when explaining the more advanced case of association specialization. The text references an earlier very brief description of end features in 7.3.4.2 (Feature Declaration), which points back to 7.4.5 for more information.
    • third paragraph (the one starting "An association is also a relationship between the types") describes related types, but does not mention these are same as the end feature types, as specified by the deriveAssociationRelatedType constraint in 8.3.4.4.2 (Association).

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

  • Reported: KerML 1.0b1 — Thu, 7 Sep 2023 15:33 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Serious limitation of textual concrete syntax as model interchange format

  • Key: KERML-205
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Root namespaces restricted to one single file

  • Key: KERML-163
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Read only, misleading keyword, metaproperty name

  • Key: KERML-206
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Mon, 30 Oct 2023 19:10 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Ambiguity In Directionality InOut semantics

  • Key: KERML-168
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

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

  • Key: KERML-197
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Annex A coverage

  • Key: KERML-207
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Composite feature values can have more than one owner

  • Key: KERML-208
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    7.3.4.1 (Features Overview) says

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

    and 8.3.3.3.3 (Feature) says

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

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

  • Reported: KerML 1.0b1 — Tue, 7 Nov 2023 16:41 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Some syntax in Core has time-dependent semantics

  • Key: KERML-211
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

TimeOf::timeContinuityConstraint might be too restrictive

  • Key: KERML-233
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 15:00 GMT

Semantic constraint needed for result type of a "constructor" expression

  • Key: KERML-244
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

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

  • Reported: KerML 1.0b1 — Fri, 1 Dec 2023 20:59 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

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

  • Updated: Tue, 1 Jul 2025 14:59 GMT

KerML should have syntax for enumerations

  • Key: KERML-245
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    SysML v2 includes syntax for enumeration definitions and usages. The semantics for enumerations are based on the general variation/variant semantics in SysML v2, which is itself based on KerML semantics. However, there currently is no syntax for enumerations in KerML. In particular, this leads to an awkward mapping in 9.2.17 KerML of MOF enumerations to KerML data types without specific syntax for enumeration.

    Enumerations are the only modeling element in the CMOF subset of UML that does not have a clear mapping to a KerML element. Especially as KerML is considered further for use as the basis of other languages, including their reflective abstract syntaxes, it would be better if enumeration syntax was codified in KerML. This would also make it easier to incorporate enumerations consistently into SysML v2 and future KerML-based languages themselves.

  • Reported: SysML 2.0b1 — Fri, 8 Dec 2023 16:02 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

isDerived, semantics

  • Key: KERML-246
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

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

  • Key: KERML-258
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

Space triggers missings

  • Key: KERML-283
  • Status: closed  
  • 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
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

Time and space life/slice/portion modeling patterns are missing

  • Key: KERML-306
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

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

  • Reported: KerML 1.0b1 — Mon, 1 Jan 2024 16:02 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

checkFeatureParameterRedefinition fails for named-argument invocations

  • Key: KERML-308
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

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

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

  • Reported: KerML 1.0b1 — Mon, 8 Jan 2024 04:35 GMT
  • Disposition: Deferred — KerML 1.0b2
  • Disposition Summary:

    Defer

    This issue was submitted after the end of the comment period, and the FTF has decided to defer its consideration to a future FTF or RTF.

  • Updated: Tue, 1 Jul 2025 14:59 GMT

Behavior portions must be classified by the same behavior they are portions of

  • Key: KERML-204
  • Status: closed  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

  • Reported: KerML 1.0b1 — Mon, 23 Oct 2023 17:58 GMT
  • Disposition: Resolved — KerML 1.0b2
  • Disposition Summary:

    Revise portion semantic constraints

    This resolution addresses the stated issue by removing the statement that portions "must be classified the same way as the Occurrences they are portionsOf, or more specialized." (9.2.4.1 Occurrences Overview), which is not currently formally enforced by any constraint. It also adds a semantic constraint requiring a portion Feature owned by a Class to specialize Occurrence::portions. The proposed OCL is exactly parallel to the existing semantic constraint checkFeatureSuboccurrenceSpecialization that reauires a composite Feature to specialize Occurrence::suboccurrences.

  • Updated: Tue, 1 Jul 2025 14:59 GMT