Kernel Modeling Language Avatar
  1. OMG Specification

Kernel Modeling Language — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
KERML_-42 Association end feature description missing simple example and equivalence to related types KerML 1.0b1 open
KERML_-38 Inherited multiplicities, semantics KerML 1.0b1 open
KERML_-57 Time and space life/slice/portion modeling patterns are missing KerML 1.0b1 open
KERML_-49 Composite feature values can have more than one owner KerML 1.0b1 open
KERML_-37 Add derived property for targetFeature KerML 1.0b1 open
KERML-204 Behavior portions must be classified by the same behavior they are portions of KerML 1.0b1 open
KERML_-46 Serious limitation of textual concrete syntax as model interchange format KerML 1.0b1 open
KERML_-52 Semantic constraint needed for result type of a "constructor" expression KerML 1.0b1 open
KERML_-86 Confusing "Classes" with "Structures" KerML 1.0b1 open
KERML_-1 isEnd of the redefining feature must match isEnd of the redefined feature KerML 1.0b1 open
KERML_-58 checkFeatureParameterRedefinition fails for named-argument invocations KerML 1.0b1 open
KERML-308 checkFeatureParameterRedefinition fails for named-argument invocations KerML 1.0b1 open
KERML-306 Time and space life/slice/portion modeling patterns are missing KerML 1.0b1 open
KERML-246 isDerived, semantics KerML 1.0b1 open
KERML-283 Space triggers missings KerML 1.0b1 open
KERML_-56 Space triggers missings KerML 1.0b1 open
KERML_-54 isDerived, semantics KerML 1.0b1 open
KERML-208 Composite feature values can have more than one owner KerML 1.0b1 open
KERML-244 Semantic constraint needed for result type of a "constructor" expression KerML 1.0b1 open
KERML-207 Annex A coverage KerML 1.0b1 open
KERML_-48 Annex A coverage KerML 1.0b1 open
KERML-168 Ambiguity In Directionality InOut semantics KerML 1.0b1 open
KERML-197 Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature KerML 1.0b1 open
KERML-206 Read only, misleading keyword, metaproperty name KerML 1.0b1 open
KERML-205 Serious limitation of textual concrete syntax as model interchange format KerML 1.0b1 open
KERML_-45 Redefining features sometimes must respecify metaproperties even when they are the same as those of the redefined feature KerML 1.0b1 open
KERML_-44 Ambiguity In Directionality InOut semantics KerML 1.0b1 open
KERML_-47 Read only, misleading keyword, metaproperty name KerML 1.0b1 open
KERML-159 Association end feature description missing simple example and equivalence to related types KerML 1.0b1 open
KERML-127 Add validateSubsettingTypeConformance constraint KerML 1.0b1 open
KERML-163 Root namespaces restricted to one single file KerML 1.0b1 open
KERML_-43 Root namespaces restricted to one single file KerML 1.0b1 open
KERML_-40 Add validateSubsettingTypeConformance constraint KerML 1.0b1 open
KERML-97 validateAssociationStructureIntersection seems vacuous KerML 1.0b1 open
KERML-124 Inherited multiplicities, semantics KerML 1.0b1 open
KERML-123 Add derived property for targetFeature KerML 1.0b1 open
KERML-116 FeatureMembership owningType attribute ambiguity KerML 1.0b1 open
KERML_-35 FeatureMembership owningType attribute ambiguity KerML 1.0b1 open
KERML_-34 validateAssociationStructureIntersection seems vacuous KerML 1.0b1 open
KERML-95 validateTypeAtMostOneConjugator OCL is wrong KerML 1.0b1 open
KERML-101 NamespaceImport Description Incorrect KerML 1.0b1 open
KERML-107 validateSpecificationSpecificNotConjugated Typo and over Constraint KerML 1.0b1 open
KERML-102 OwningMembership Description ownedMemberElement typo KerML 1.0b1 open
KERML-113 deriveFeatureOwnedSubsetting text references wrong attribute KerML 1.0b1 open
KERML-103 deriveElementIsLibraryElement Typo KerML 1.0b1 open
KERML-115 FeatureMembership Description Typo KerML 1.0b1 open
KERML-100 Namespace Description Textual Errors KerML 1.0b1 open
KERML-96 validateSpecializationSpecificNotConjugated documentation is wrong KerML 1.0b1 open
KERML-99 deriveMembershipMemberElementId text elementId typo KerML 1.0b1 open
KERML-118 deriveFeatureFeaturingType conflicts with owningType KerML 1.0b1 open
KERML-117 deriveTypeFeatureMembership incorrect unioning KerML 1.0b1 open
KERML-122 validateClassSpecialization is too strict KerML 1.0b1 open
KERML-151 deriveFeatureType is not correct KerML 1.0b1 open
KERML-112 deriveTypeOwned TypeRelationship constraints have incomplete OCL KerML 1.0b1 open
KERML-177 Legacy, so incorrect, wording in Anything Description KerML 1.0b1 open
KERML-175 Natural unnecessary explicit general type declaration KerML 1.0b1 open
KERML-176 Base Overview Typo KerML 1.0b1 open
KERML-180 Occurrences Overview Typo KerML 1.0b1 open
KERML-184 Update Kernel Model Libraries for validateFeatureValueOverriding constraint KerML 1.0b1 open
KERML-195 Transfer sourceOutput and targetInput directions KerML 1.0b1 open
KERML-227 Documentation of features in Transfers library model is wrong KerML 1.0b1 open
KERML-188 DataFunctions::Min and Max should not be capitalized KerML 1.0b1 open
KERML-198 Wrong documentation format for class Occurrence in Semantic Library KerML 1.0b1 open
KERML-178 Anything.self subsetting Inconsistent declaration with Base.kerml declaration KerML 1.0b1 open
KERML-182 Update Kernel Semantic Library for validateRedefinitionDirectionConformance constraint KerML 1.0b1 open
KERML-105 Car necessary and sufficiency example KerML 1.0b1 open
KERML-104 Type Membership Multiplicity text conflict KerML 1.0b1 open
KERML-158 InsideOf association end feature redefines cross feature KerML 1.0b1 open
KERML-138 oclAsType applied to resolveGlobal KerML 1.0b1 open
KERML-109 Textual Syntax allows multiple ConjugationParts on a Type KerML 1.0b1 open
KERML-106 Protected membership inheritance through Specialization type KerML 1.0b1 open
KERML-111 Disjoining textual notation typo on disjoiningType KerML 1.0b1 open
KERML-108 Conjugation Textual Redundant Word KerML 1.0b1 open
KERML-114 FeatureDeclaration ConjugationPart lexical element incorrect reference KerML 1.0b1 open
KERML-170 checkFeatureSubobjectSpecialization incorrect Font KerML 1.0b1 open
KERML-167 Typo in Conjugation Description KerML 1.0b1 open
KERML-162 Misidentified non-terminals and misspelled non-terminals in the EBNF KerML 1.0b1 open
KERML-169 Feature isDerived metaproperty Typo KerML 1.0b1 open
KERML-160 unknown non-terminal reference in EBNF KerML 1.0b1 open
KERML-164 No production for nonterminal KerML 1.0b1 open
KERML-191 Comment textual syntax defined differently to implementation KerML 1.0b1 open
KERML-190 OwnedExpression missing ConditionalBinaryOperatorExpression KerML 1.0b1 open
KERML-171 Feature Chain relationships are inconsistent with the concrete syntax KerML 1.0b1 open
KERML-189 non-terminal does not exist in the specification KerML 1.0b1 open
KERML-181 Model Interchange Overview Typo KerML 1.0b1 open
KERML-179 checkAssociationStructureSpecialization invalid reference KerML 1.0b1 open
KERML-172 ClassifierDeclaration concrete syntax typo KerML 1.0b1 open
KERML-173 Classifier Description Typo KerML 1.0b1 open
KERML-200 Annex A (Model Execution) minor errors KerML 1.0b1 open
KERML-232 Additional problems with deriveFeatureType KerML 1.0b1 open
KERML-194 validateRedefinitionDirectionConformance does not account for conjugation KerML 1.0b1 open
KERML-236 Association SourceType Cardinality Contradiction KerML 1.0b1 open
KERML-193 Weird Concrete Syntax for ConditionalExpression KerML 1.0b1 open
KERML-192 Many mistakes and differences to implementation KerML 1.0b1 open
KERML-238 No textual syntax or derivation rules for isDirected KerML 1.0b1 open
KERML-237 Link Participant Plurality Typo in OCL KerML 1.0b1 open
KERML-241 Typo in Multiplicity Ranges Semantics KerML 1.0b1 open
KERML-240 Typo in Multiplicities Overview KerML 1.0b1 open
KERML-248 Error in Expression modelLevelEvaluable operation OCL KerML 1.0b1 open
KERML-242 Typo in checkAssociationBinarySpecialization OCL KerML 1.0b1 open
KERML-247 Typo in modelLevelEvaluable Operation text KerML 1.0b1 open
KERML-239 SelfLink::thatThing does not exist in Links Model Library KerML 1.0b1 open
KERML-186 Update semantic model of invariants for validateExpressionResultExpressionMembership constraint KerML 1.0b1 open
KERML-260 Definition of property "typing" seems incomplete/inconsistent KerML 1.0b1 open
KERML-249 Typo in Function Abstract Syntax Description KerML 1.0b1 open
KERML-250 Typo in Function Declaration Overview KerML 1.0b1 open
KERML-251 Remove disjointness of LinkObject KerML 1.0b1 open
KERML-199 validateMultiplicityRangeBoundResultTypes constraint is too strong KerML 1.0b1 open
KERML-231 LinkObject disjointness is redundant KerML 1.0b1 open
KERML-259 Reference to nonexistent class (Superclassification) in OCL rule deriveClassifierOwnedSubclassification KerML 1.0b1 open
KERML-154 Directed features inherited from a conjugated type not handled properly KerML 1.0b1 open
KERML-161 Misspelling KerML 1.0b1 open
KERML-174 DataType Disjointness Clarification KerML 1.0b1 open
KERML-165 Exponentiation should be right-associative KerML 1.0b1 open
KERML-282 Measuring devices for space missing KerML 1.0b1 open
KERML-307 User-defined keywords are not allowed on metadata features KerML 1.0b1 open
KERML-309 package "Interactions TBD" should not be included in the XMI file KerML 1.0b1 open
KERML-120 FlowTransferBefore needs end feature declarations KerML 1.0b1 open
KERML-98 Comment Locale not in textual notation KerML 1.0b1 open
KERML-110 Disjoining example conflicts with textual description KerML 1.0b1 open

Issues Descriptions

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

  • Key: KERML_-42
  • Status: open  
  • 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
  • Updated: Tue, 26 Nov 2024 00:50 GMT

Inherited multiplicities, semantics

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

    Clause 8.4.4.12.1 (Multiplicities, Semantics) says

    The validateTypeOwnedMultiplicity constraint requires that a Type have at most one ownedMember that is a Multiplicity. If a Type has such an owned Multiplicity, then it is the typeWithMultiplicity of that Multiplicity. The value of the Multiplicity is then the cardinality of its typeWithMultiplicity and, therefore, the type (co-domain) of the Multiplicity restricts that cardinality.

    If a Type does not have an owned Multiplicity, but has ownedSpecializations, then its cardinality is constrained by the Multiplicities for all of the general Types of those ownedSpecializations (i.e., its direct supertypes). In practice, this means that the effective Multiplicity of the Type is the most restrictive Multiplicity of its direct supertypes.

    The above implies inherited multiplicities do not constrain cardinality of types that

    • own a Multiplicity
    • inherit them via unowned specializations

    while the (math) semantics for specialization and multiplicity says they do (rule 1 in 8.4.3.2, Types Semantics, and rule 5 in 8.4.3.4, Features Semantics, respectively).

  • Reported: KerML 1.0b1 — Sat, 29 Jul 2023 14:44 GMT
  • Updated: Sun, 10 Nov 2024 18:17 GMT

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

  • Key: KERML_-57
  • Status: open  
  • 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
  • Updated: Tue, 29 Oct 2024 18:58 GMT
  • Attachments:

Composite feature values can have more than one owner

  • Key: KERML_-49
  • Status: open  
  • 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
  • Updated: Sun, 25 Aug 2024 14:53 GMT

Add derived property for targetFeature

  • Key: KERML_-37
  • Status: open  
  • 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
  • Updated: Tue, 30 Jul 2024 23:14 GMT
  • Attachments:

Behavior portions must be classified by the same behavior they are portions of

  • Key: KERML-204
  • Status: open  
  • 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
  • Updated: Mon, 22 Jul 2024 16:01 GMT

Serious limitation of textual concrete syntax as model interchange format

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

    The specification in subclause 10.2 lists the textual concrete syntax as one format for model interchange.

    However, the textual concrete syntax does not include syntax for the elementId : UUID property of any element specified in such a model interchange. In general, this makes it impossible to derive the net semantic difference between model interchanges of a pair of revisions (or versions) of the same package represented in this format. The elementId identifiers are necessary to detect whether a change constitutes: (1) a newly created element, (2) an updated element (including a moved element), or (3) a deleted element. In general, it will only be possible to derive the net lexical difference. This limitation holds in particular for unnamed (i.e. anonymous) elements, as well as for elements with name and/or shortName changes.

    It is therefore debatable whether the textual concrete syntax may be designated as a proper model interchange format.

    This limitation of use of the textual concrete syntax as an interchange format should be explicitly addressed through one of the following:

    1. Add an explanation of the limitation in the specification.
    2. Add a facility in the textual concrete syntax to include representation of the elementId for any element. For usability reasons, implementations should provide a capability to show or hide the elementId snippets in the concrete textual notation editor widgets.
  • Reported: KerML 1.0b1 — Sat, 28 Oct 2023 14:22 GMT
  • Updated: Mon, 15 Jul 2024 19:23 GMT

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

  • Key: KERML_-52
  • Status: open  
  • 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
  • Updated: Sat, 6 Jul 2024 15:26 GMT

Confusing "Classes" with "Structures"

  • Key: KERML_-86
  • Status: open  
  • 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
  • Updated: Tue, 2 Jul 2024 11:39 GMT

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

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

  • Reported: KerML 1.0b1 — Fri, 22 Mar 2024 19:18 GMT
  • Updated: Wed, 17 Apr 2024 21:18 GMT

checkFeatureParameterRedefinition fails for named-argument invocations

  • Key: KERML_-58
  • Status: open  
  • 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
  • Updated: Wed, 17 Apr 2024 20:15 GMT

checkFeatureParameterRedefinition fails for named-argument invocations

  • Key: KERML-308
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

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

  • Key: KERML-306
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

isDerived, semantics

  • Key: KERML-246
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

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

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

    but this semantics is not model/mathed.

  • Reported: KerML 1.0b1 — Thu, 14 Dec 2023 15:32 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Space triggers missings

  • Key: KERML-283
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Thu, 21 Dec 2023 17:05 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Space triggers missings

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

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

  • Reported: KerML 1.0b1 — Thu, 21 Dec 2023 17:05 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

isDerived, semantics

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

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

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

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

    but this semantics is not model/mathed.

  • Reported: KerML 1.0b1 — Thu, 14 Dec 2023 15:32 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Composite feature values can have more than one owner

  • Key: KERML-208
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

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

  • Key: KERML-244
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Annex A coverage

  • Key: KERML-207
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    The execution algorithm in Annex A should could more cases.

  • Reported: KerML 1.0b1 — Wed, 1 Nov 2023 20:08 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Annex A coverage

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

    The execution algorithm in Annex A should could more cases.

  • Reported: KerML 1.0b1 — Wed, 1 Nov 2023 20:08 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Ambiguity In Directionality InOut semantics

  • Key: KERML-168
  • Status: open  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 17:58 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

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

  • Key: KERML-197
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

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

  • Reported: KerML 1.0b1 — Tue, 17 Oct 2023 19:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Read only, misleading keyword, metaproperty name

  • Key: KERML-206
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Serious limitation of textual concrete syntax as model interchange format

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

    The specification in subclause 10.2 lists the textual concrete syntax as one format for model interchange.

    However, the textual concrete syntax does not include syntax for the elementId : UUID property of any element specified in such a model interchange. In general, this makes it impossible to derive the net semantic difference between model interchanges of a pair of revisions (or versions) of the same package represented in this format. The elementId identifiers are necessary to detect whether a change constitutes: (1) a newly created element, (2) an updated element (including a moved element), or (3) a deleted element. In general, it will only be possible to derive the net lexical difference. This limitation holds in particular for unnamed (i.e. anonymous) elements, as well as for elements with name and/or shortName changes.

    It is therefore debatable whether the textual concrete syntax may be designated as a proper model interchange format.

    This limitation of use of the textual concrete syntax as an interchange format should be explicitly addressed through one of the following:

    1. Add an explanation of the limitation in the specification.
    2. Add a facility in the textual concrete syntax to include representation of the elementId for any element. For usability reasons, implementations should provide a capability to show or hide the elementId snippets in the concrete textual notation editor widgets.
  • Reported: KerML 1.0b1 — Sat, 28 Oct 2023 14:22 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

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

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

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

  • Reported: KerML 1.0b1 — Tue, 17 Oct 2023 19:02 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Ambiguity In Directionality InOut semantics

  • Key: KERML_-44
  • Status: open  
  • Source: Self ( Jim Ciarcia)
  • Summary:

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

  • Reported: KerML 1.0b1 — Sat, 16 Sep 2023 17:58 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Read only, misleading keyword, metaproperty name

  • Key: KERML_-47
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

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

  • Key: KERML-159
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Add validateSubsettingTypeConformance constraint

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

    There is currently no constraint that the typing of a subsetting feature conform to the typing of the subsetted feature. For example, the following is currently considered valid:

    classifier A;
    classifier B;
    
    feature x : A;
    feature y : B subsets x;
    

    even if there is no specialization relationship between A and B. Currently, what happens is that y picks up the additions the additional type A due to the subsetting. So the above declaration for y is essentially equivalent to

    feature y: B, A subsets x;
    

    Now, unless A and B are declared as disjoint, it is possible that there are instances classified by both A and B, so that this joint typing of y isn't vacuous. Nevertheless, it seems more useful, for static type checking, to presume disjointness and to disallow the above subsetting unless B can be statically determined to specialize A.

    This is relevant, in particular, for connectors, in which the related features are determined using reference subsetting. Consider the following:

    assoc C {
       end a: A;
       end b: B;
    }
    
    feature a1: A;
    feature b1: B;
    
    connector c: C from a ::> b1 to b ::> a1;
    

    Because of the above, this is currently allowed. But, as a result, this really seems to make the typing of association ends pretty much useless for connectors.

  • Reported: KerML 1.0b1 — Tue, 1 Aug 2023 15:32 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Root namespaces restricted to one single file

  • Key: KERML-163
  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Usecase: large corporation is working on a project, where also other suppliers deliver parts of the product architecture.

    To avoid naming collisions in such constellations, it makes sense to use hierarchical package structures. If everyone just uses plain structures, we have potential conflicts with a duplicate declaration of namespaces.
    As within large corporations hundreds of engineers can be working of one product class, which might be organized as namespaces, it makes sense to split the definition of multiple namespaces within the same parent namespace in different files to avoid merge conflicts

    Example

    package Vehicle{
       part engine : MyCorp::Automotive::Engine::SmallEngine;
       part gearFront : MyCorp::Automotive::Transmission::AT8Gear;
       part rearGear : SomeSupplier::Transmission::FancyGear;
    }
    

    Possible resolutions:
    1) allow duplicate definitions of namespaces and implicitly merges the resulting trees, dangerous as it could happen unintended
    2) allow to merge sub-trees of duplicate namespaces with a keyword
    2a) all except one namespace declaration require an addendum keyword, injection of elements possible which might expose private information
    2b) all namespaces must declare, that extension is possible

    example

    partial package CommonParent //declaration can be skipped, if nothing except namespace is declared
    package CommonParent::GroupA{
      //some declarations
    }
    package CommonParent::GroupB{
      //some more declarations
    }
    package CommonParent::IntegrationLayer{} //should work as no explicitly declared namespace is duplicated
    package CommonParent::GroupA::Backdoor {} //should generate an error as the explicitly declared namespace GroupA is duplicated
    
  • Reported: KerML 1.0b1 — Mon, 11 Sep 2023 17:55 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Root namespaces restricted to one single file

  • Key: KERML_-43
  • Status: open  
  • Source: Robert Bosch GmbH ( Florian Beer)
  • Summary:

    Usecase: large corporation is working on a project, where also other suppliers deliver parts of the product architecture.

    To avoid naming collisions in such constellations, it makes sense to use hierarchical package structures. If everyone just uses plain structures, we have potential conflicts with a duplicate declaration of namespaces.
    As within large corporations hundreds of engineers can be working of one product class, which might be organized as namespaces, it makes sense to split the definition of multiple namespaces within the same parent namespace in different files to avoid merge conflicts

    Example

    package Vehicle{
       part engine : MyCorp::Automotive::Engine::SmallEngine;
       part gearFront : MyCorp::Automotive::Transmission::AT8Gear;
       part rearGear : SomeSupplier::Transmission::FancyGear;
    }
    

    Possible resolutions:
    1) allow duplicate definitions of namespaces and implicitly merges the resulting trees, dangerous as it could happen unintended
    2) allow to merge sub-trees of duplicate namespaces with a keyword
    2a) all except one namespace declaration require an addendum keyword, injection of elements possible which might expose private information
    2b) all namespaces must declare, that extension is possible

    example

    partial package CommonParent //declaration can be skipped, if nothing except namespace is declared
    package CommonParent::GroupA{
      //some declarations
    }
    package CommonParent::GroupB{
      //some more declarations
    }
    package CommonParent::IntegrationLayer{} //should work as no explicitly declared namespace is duplicated
    package CommonParent::GroupA::Backdoor {} //should generate an error as the explicitly declared namespace GroupA is duplicated
    
  • Reported: KerML 1.0b1 — Mon, 11 Sep 2023 17:55 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Add validateSubsettingTypeConformance constraint

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

    There is currently no constraint that the typing of a subsetting feature conform to the typing of the subsetted feature. For example, the following is currently considered valid:

    classifier A;
    classifier B;
    
    feature x : A;
    feature y : B subsets x;
    

    even if there is no specialization relationship between A and B. Currently, what happens is that y picks up the additions the additional type A due to the subsetting. So the above declaration for y is essentially equivalent to

    feature y: B, A subsets x;
    

    Now, unless A and B are declared as disjoint, it is possible that there are instances classified by both A and B, so that this joint typing of y isn't vacuous. Nevertheless, it seems more useful, for static type checking, to presume disjointness and to disallow the above subsetting unless B can be statically determined to specialize A.

    This is relevant, in particular, for connectors, in which the related features are determined using reference subsetting. Consider the following:

    assoc C {
       end a: A;
       end b: B;
    }
    
    feature a1: A;
    feature b1: B;
    
    connector c: C from a ::> b1 to b ::> a1;
    

    Because of the above, this is currently allowed. But, as a result, this really seems to make the typing of association ends pretty much useless for connectors.

  • Reported: KerML 1.0b1 — Tue, 1 Aug 2023 15:32 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

validateAssociationStructureIntersection seems vacuous

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

    The documentation for the validateAssociationStructureIntersection constraint is "If an Association is also a kind of Structure, then it must be an AssociationStructure." with the OCL

    oclIsKindOf(Structure) = oclIsKindOf(AssociationStructure)
    

    However, this is really a constraint on the abstract syntax, not user models. Since the current abstract syntax does not have any metaclass that is a subclass of both Structure and Association other than AssociationStructure, this constraint will always be true for every user model. (And, if the abstract syntax did include another subclass of both Structure and Association, then constraint would then be violated by every user model that used that construct!)

  • Reported: KerML 1.0b1 — Tue, 11 Jul 2023 20:11 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Inherited multiplicities, semantics

  • Key: KERML-124
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Clause 8.4.4.12.1 (Multiplicities, Semantics) says

    The validateTypeOwnedMultiplicity constraint requires that a Type have at most one ownedMember that is a Multiplicity. If a Type has such an owned Multiplicity, then it is the typeWithMultiplicity of that Multiplicity. The value of the Multiplicity is then the cardinality of its typeWithMultiplicity and, therefore, the type (co-domain) of the Multiplicity restricts that cardinality.

    If a Type does not have an owned Multiplicity, but has ownedSpecializations, then its cardinality is constrained by the Multiplicities for all of the general Types of those ownedSpecializations (i.e., its direct supertypes). In practice, this means that the effective Multiplicity of the Type is the most restrictive Multiplicity of its direct supertypes.

    The above implies inherited multiplicities do not constrain cardinality of types that

    • own a Multiplicity
    • inherit them via unowned specializations

    while the (math) semantics for specialization and multiplicity says they do (rule 1 in 8.4.3.2, Types Semantics, and rule 5 in 8.4.3.4, Features Semantics, respectively).

  • Reported: KerML 1.0b1 — Sat, 29 Jul 2023 14:44 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

Add derived property for targetFeature

  • Key: KERML-123
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

FeatureMembership owningType attribute ambiguity

  • Key: KERML-116
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

FeatureMembership owningType attribute ambiguity

  • Key: KERML_-35
  • Status: open  
  • 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
  • Updated: Tue, 9 Apr 2024 23:30 GMT

validateAssociationStructureIntersection seems vacuous

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

    The documentation for the validateAssociationStructureIntersection constraint is "If an Association is also a kind of Structure, then it must be an AssociationStructure." with the OCL

    oclIsKindOf(Structure) = oclIsKindOf(AssociationStructure)
    

    However, this is really a constraint on the abstract syntax, not user models. Since the current abstract syntax does not have any metaclass that is a subclass of both Structure and Association other than AssociationStructure, this constraint will always be true for every user model. (And, if the abstract syntax did include another subclass of both Structure and Association, then constraint would then be violated by every user model that used that construct!)

  • Reported: KerML 1.0b1 — Tue, 11 Jul 2023 20:11 GMT
  • Updated: Tue, 9 Apr 2024 23:30 GMT

validateTypeAtMostOneConjugator OCL is wrong

  • Key: KERML-95
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

NamespaceImport Description Incorrect

  • Key: KERML-101
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

validateSpecificationSpecificNotConjugated Typo and over Constraint

  • Key: KERML-107
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

OwningMembership Description ownedMemberElement typo

  • Key: KERML-102
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveFeatureOwnedSubsetting text references wrong attribute

  • Key: KERML-113
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveElementIsLibraryElement Typo

  • Key: KERML-103
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

FeatureMembership Description Typo

  • Key: KERML-115
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Namespace Description Textual Errors

  • Key: KERML-100
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

validateSpecializationSpecificNotConjugated documentation is wrong

  • Key: KERML-96
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveMembershipMemberElementId text elementId typo

  • Key: KERML-99
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveFeatureFeaturingType conflicts with owningType

  • Key: KERML-118
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveTypeFeatureMembership incorrect unioning

  • Key: KERML-117
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

validateClassSpecialization is too strict

  • Key: KERML-122
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveFeatureType is not correct

  • Key: KERML-151
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

deriveTypeOwned TypeRelationship constraints have incomplete OCL

  • Key: KERML-112
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Legacy, so incorrect, wording in Anything Description

  • Key: KERML-177
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Natural unnecessary explicit general type declaration

  • Key: KERML-175
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Base Overview Typo

  • Key: KERML-176
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Occurrences Overview Typo

  • Key: KERML-180
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Update Kernel Model Libraries for validateFeatureValueOverriding constraint

  • Key: KERML-184
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Transfer sourceOutput and targetInput directions

  • Key: KERML-195
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Documentation of features in Transfers library model is wrong

  • Key: KERML-227
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

DataFunctions::Min and Max should not be capitalized

  • Key: KERML-188
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Wrong documentation format for class Occurrence in Semantic Library

  • Key: KERML-198
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Anything.self subsetting Inconsistent declaration with Base.kerml declaration

  • Key: KERML-178
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Update Kernel Semantic Library for validateRedefinitionDirectionConformance constraint

  • Key: KERML-182
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Car necessary and sufficiency example

  • Key: KERML-105
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Type Membership Multiplicity text conflict

  • Key: KERML-104
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

InsideOf association end feature redefines cross feature

  • Key: KERML-158
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

oclAsType applied to resolveGlobal

  • Key: KERML-138
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Textual Syntax allows multiple ConjugationParts on a Type

  • Key: KERML-109
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Protected membership inheritance through Specialization type

  • Key: KERML-106
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Disjoining textual notation typo on disjoiningType

  • Key: KERML-111
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Conjugation Textual Redundant Word

  • Key: KERML-108
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

FeatureDeclaration ConjugationPart lexical element incorrect reference

  • Key: KERML-114
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

checkFeatureSubobjectSpecialization incorrect Font

  • Key: KERML-170
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in Conjugation Description

  • Key: KERML-167
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Misidentified non-terminals and misspelled non-terminals in the EBNF

  • Key: KERML-162
  • Status: open   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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Feature isDerived metaproperty Typo

  • Key: KERML-169
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

unknown non-terminal reference in EBNF

  • Key: KERML-160
  • Status: open   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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

No production for nonterminal

  • Key: KERML-164
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Comment textual syntax defined differently to implementation

  • Key: KERML-191
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

OwnedExpression missing ConditionalBinaryOperatorExpression

  • Key: KERML-190
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Feature Chain relationships are inconsistent with the concrete syntax

  • Key: KERML-171
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

non-terminal does not exist in the specification

  • Key: KERML-189
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Model Interchange Overview Typo

  • Key: KERML-181
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

checkAssociationStructureSpecialization invalid reference

  • Key: KERML-179
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

ClassifierDeclaration concrete syntax typo

  • Key: KERML-172
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Classifier Description Typo

  • Key: KERML-173
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Annex A (Model Execution) minor errors

  • Key: KERML-200
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT
  • Attachments:

Additional problems with deriveFeatureType

  • Key: KERML-232
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

validateRedefinitionDirectionConformance does not account for conjugation

  • Key: KERML-194
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Association SourceType Cardinality Contradiction

  • Key: KERML-236
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Weird Concrete Syntax for ConditionalExpression

  • Key: KERML-193
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Many mistakes and differences to implementation

  • Key: KERML-192
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

No textual syntax or derivation rules for isDirected

  • Key: KERML-238
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Link Participant Plurality Typo in OCL

  • Key: KERML-237
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in Multiplicity Ranges Semantics

  • Key: KERML-241
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in Multiplicities Overview

  • Key: KERML-240
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Error in Expression modelLevelEvaluable operation OCL

  • Key: KERML-248
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in checkAssociationBinarySpecialization OCL

  • Key: KERML-242
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in modelLevelEvaluable Operation text

  • Key: KERML-247
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

SelfLink::thatThing does not exist in Links Model Library

  • Key: KERML-239
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Update semantic model of invariants for validateExpressionResultExpressionMembership constraint

  • Key: KERML-186
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Definition of property "typing" seems incomplete/inconsistent

  • Key: KERML-260
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in Function Abstract Syntax Description

  • Key: KERML-249
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Typo in Function Declaration Overview

  • Key: KERML-250
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Remove disjointness of LinkObject

  • Key: KERML-251
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

validateMultiplicityRangeBoundResultTypes constraint is too strong

  • Key: KERML-199
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

LinkObject disjointness is redundant

  • Key: KERML-231
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Reference to nonexistent class (Superclassification) in OCL rule deriveClassifierOwnedSubclassification

  • Key: KERML-259
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Directed features inherited from a conjugated type not handled properly

  • Key: KERML-154
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Misspelling

  • Key: KERML-161
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

DataType Disjointness Clarification

  • Key: KERML-174
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Exponentiation should be right-associative

  • Key: KERML-165
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Measuring devices for space missing

  • Key: KERML-282
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

User-defined keywords are not allowed on metadata features

  • Key: KERML-307
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

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

  • Key: KERML-309
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

FlowTransferBefore needs end feature declarations

  • Key: KERML-120
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Comment Locale not in textual notation

  • Key: KERML-98
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT

Disjoining example conflicts with textual description

  • Key: KERML-110
  • Status: open  
  • 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
  • Updated: Mon, 8 Apr 2024 21:42 GMT