Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

Throughout the document, we need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

Throughout the document, need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

I raised a number of issues previously with regards to detailed/specific problems with the KerML textual syntax grammar.
A more general issue is that I find the grammar (as written) hard to digest.
It is not modular, and the chapters don't seem to relate fully to the Abstract Syntax packages.

I have created an alternative grammar, using a different grammar-syntax, that allows for modular definition of grammars.
I would like to offer you this.
However, I cannot attach files to this issue!
feel free to contact me if you would like me to provide them.

In summary, one can modularise the KerML grammar into a Kernel, Core, Root (groups/packages)
with each group/package containing 3-5 grammar modules and extension relationships to combine them.

I plan to do the same for the full SysML grammar (later).

The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

(This issue was originally reported as part of SYSML2-635.)

The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

(This issue was originally reported as part of SYSML2-635.)

The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

[From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

enum def ClassificationLevel {
   enum unclassified;
   enum cui;
   enum secret;
   enum top_secret;
}

enum def ClassificationLevelClassified :> ClassificationLevel {
    enum secret;
    enum top_secret;
}

According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

[From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

enum def ClassificationLevel {
   enum unclassified;
   enum cui;
   enum secret;
   enum top_secret;
}

enum def ClassificationLevelClassified :> ClassificationLevel {
    enum secret;
    enum top_secret;
}

The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

The concrete syntax should be updated accordingly.

A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

The concrete syntax should be updated accordingly.

According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

send payloadExpression via senderExpression to receiverExpression

In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

send payloadExpression via senderExpression to receiverExpression

In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

Clause 8.4.5.2 (Occurrence Usages) says

If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
...

and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

Clause 8.4.5.2 (Occurrence Usages) says

If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
...

and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

Informal specification of requirements is realized as body of the documentation.
Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

• add optional 'language' keyword to doc
• define the folder containing the sysml file as root for references made from documentation elements within this file

To provide guidance for users on common formatting

• reference jpg and png as suggested image formats
• reference markdown "md" or other low-complex language as suggested formatting language

example:
requirement def SomeRequirement

Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

The transformation ignores the entry, do, and exit behavior of a state.

The transformation ignores the entry, do, and exit behavior of a state.

Informal specification of requirements is realized as body of the documentation.
Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

• add optional 'language' keyword to doc
• define the folder containing the sysml file as root for references made from documentation elements within this file

To provide guidance for users on common formatting

• reference jpg and png as suggested image formats
• reference markdown "md" or other low-complex language as suggested formatting language

example:
requirement def SomeRequirement

Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
transition normal_To_degraded
first normal
accept when senseTemperature.temp > Tmax
do send OverTemp() via targetPort
then degraded;

In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
transition normal_To_maintenance
first normal
accept at maintenanceTime
then maintenance;

Clause 7.13.3 (Bindings as Usages) says

The end features of a binding always have multiplicity [1..1].

and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

checkTransitionUsageSuccessionBindingConnector
A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
ownedMember->selectByKind(BindingConnector)->exists(b |
b.relatedFeatures->includes(succession) and
b.relatedFeatures->includes(resolveGlobal(
'TransitionPerformances::TransitionPerformance::transitionLink')))

with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

Clause 7.13.3 (Bindings as Usages) says

The end features of a binding always have multiplicity [1..1].

and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

checkTransitionUsageSuccessionBindingConnector
A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
ownedMember->selectByKind(BindingConnector)->exists(b |
b.relatedFeatures->includes(succession) and
b.relatedFeatures->includes(resolveGlobal(
'TransitionPerformances::TransitionPerformance::transitionLink')))

with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
transition normal_To_maintenance
first normal
accept at maintenanceTime
then maintenance;

In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
transition normal_To_degraded
first normal
accept when senseTemperature.temp > Tmax
do send OverTemp() via targetPort
then degraded;

The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

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

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

while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

checkDecisionNodeOutgoingSuccessionSpecialization
All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

checkMergeNodeIncomingSuccessionSpecialization
All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

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

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

while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

checkDecisionNodeOutgoingSuccessionSpecialization
All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

checkMergeNodeIncomingSuccessionSpecialization
All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

Add import qualifier text (* or **) to upper right corner of imported Package

Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

Add import qualifier text (* or **) to upper right corner of imported Package

Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

Clarify that the identifier for the metadata declaration is the metadata definition name.

In the param-t production the nesting parameter pdv is missing an optional nested param-t* element.

Clarify that the identifier for the metadata declaration is the metadata definition name.

Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

The transformation does not map the Parameter::isStreaming.

There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

The transformation does not map the Parameter::isStreaming.

The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

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

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

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

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

The SysML v1 to v2 transformation does not map ActivityParameterNode, but only the references Parameter. The mapping of ActivityEdge must map the ends of the edge, which are connected to an ActivityParameterNode to the target element of the mapping of the Parameter.

Table 19, Requirement, compartment for require constraints:

Typo in compartment headline should be "require constraints" => "requirre"

A succession relationship on an action flow should be a solid line with an open arrow head. In 7.16.1 in example "Accept and Send Action Flow". Check for other locations.

The nesting parameter symbol productions (for actions) must have rounded corners, since they are (parameter) usages.

Example "Package with imported packages (nested packages)" should have «private» enclosed by guillemets

Example "Usage Definition" should be labeled "Part defined by Part Definition"

In example "Relationships Compartment" add textual notation that matches the graphical notation. Also "connect part3" in second symbol should be removed.

In example "Variant Membership" the variants should be defined by Part1a and Part1b respectively. Currently they are both defined by Part1.

In example "Occurrences Compartment" add abstract occurrence feature for completeness.

In example "Attributes Compartment" textual notation should use nonunique instead of unique.

Remove nested features (textual) notation from compartments in graphical symbols in all Representative Notation tables where they occur. This capability was discarded.

Simplify examples "Timeslices Compartment" and "Snapshots Compartment" by putting the compartments into a «part» context, and add e.g. phase1 and phase2 timeslices, and e.g. snapshot1 and snapshot2.

In example "Part with Graphical Compartment with perform actions and flows between them." add «perform action» to both action2 and action3.

In example "Connection" (1) remove circumflex on end1 and end2, since they are (implicitly) redefinitions of the ends from the connection definition, not inherited features.

In examples "Timeslices Compartment" and "Snapshots Compartment" remove state state1 feature, since it is confusing, and potentially incorrect.

Replace nested reference usage notation with dotted outline notation. Add BNF production for this notation.
Reference usage notation is used in interconnection diagrams, and potentially action flow diagram. The solution is to add explicit production for dotted usages of parts, constraints, and requirements references and include those production in interconnection diagrams. Create productions of action usage references and add them to action flow.

In example "Part with Ports" remove "Nested" from NestedPortDef0.

In example "Documentation Compartment", the documentation keyword should read doc

In example "Message" the arrow head should be moved to the end of the line, and should be adorned "message of item1:Item1".

The constraints validateDefinitionVariationMembership and validationUsageVariationMembership require that all the owned members of a variation definition or usage be variant members. This is too strong:

• It disallows any variation Usage from having a Multiplicity, because that is a non-variant owned member of the Usage.
• It disallows a variation PortDefinition from having a required ConjugatedPortDefinition, because that is a non-variant owned member of the definition.

The constraint validateFramedConcernUsageConstraintKind is owned by FramedConcernMembership, not FramedConcernUsage (which doesn't exist). Therefore, the constraint should be named validateFramedConcernMembershipConstraintKind.

The constraints validateDefinitionNonVariationMembership and validateUsageNonVariationMembership check that a non-variation Definition or Usage owns no VariantMemberships. However, validateVariantMembershipOwningNamespace already checks that the membershipOwningNamespace of a VariantMembership is a variation, so the other constraints are redundant.

The validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization prohibit parallel state definitions and usages from owning specializations of non-parallel state definitions and usages (and vice versa). However, this would prevent even, e.g., an empty non-parallel state definition from having a usage that was parallel, for example:

state def S;
state s : S parallel {  // validation error!
    state s1;
    state s2;
}

Further, it is also a validation error for a parallel state definition to explicitly specialized the base state definition StateAction (which is not parallel), even though an implicit specialization is not checked:

state def S1 parallel { } // legal, implicitly specializes StateAction
state def S2 :> States::StateAction parallel { } // validation error!

For consistency, it would seem that, at least, a parallel state definition or usage should be able to explicitly specialize a non-parallel one. But perhaps the constraints are really not semantically necessary at all.

The OCL for the constraint validateOccurrenceUsageIndividualDefinition is

occurrenceDefinition->select(isIndividual).size() <= 1

However, the type of OccurrenceUsage::occurrenceDefinition is actually Class, not OccurrenceDefinition, but the property isIndividual is only defined on OccurrenceDefinition.

The constraint validateUsageOwningType constrains the owningType of a Usage to be a Definition or Usage. However, this is two restrictive, because it prevents, e.g., a Usage from being declared within a body expression (as used with collect, select, etc.), which is a KerML Expression.

The body OCL for the namingFeature operation of ConstraintUsage references ownedFeatureMembership. This should instead be owningFeatureMembership.

The OCL for the constraints validateStateDefinitionIsParallelGeneralization and validateStateUsageIsParallelGeneralization both use ownedGeneralization (which doesn't exist) instead of ownedSpecialization.

The title of 8.3.16.18 is WhileLoopsActionusage, with plural "Loops" and lower case "u", but in Figure 28 (Structured Control Actions) these are singular and capitalized, respectively.

In 8.3.17.9 (TransitionUsage), the text for checkTransitionUsageSourceBindingConnector requires binding of the first input parameter

A TransitionUsage must have an ownedMember that is a BindingConnector between its source and its first input parameter (which redefines Actions::TransitionAction::transitionLinkSource).

while the OCL gives it as binding the second parameter

ownedMember->selectByKind(BindingConnector)->exists(b |
b.relatedFeatures->includes(source) and
b.relatedFeatures->includes(inputParameter(2)))

In 8.3.16.10 (IfActionUsage), the OCL for checkIfActionUsageSpecialization refers to specifiesFromLibrary instead of specializesFromLibrary.

The mapping classes InformationFlowEnd_Mapping, InformationFlowFeatureTyping_Mapping, and InformationFlowEndFeatureMembership_Mapping updated by SYSML2-180 should use more specialized GenericTo mapping classes instead of the GenericToElement_Mapping class:

InformationFlowEnd_Mapping => GenericToFeature_Mapping
InformationFlowFeatureTyping_Mapping => GenericToFeatureTyping_Mapping
InformationFlowEndFeatureMembership_Mapping => GenericToFeatureMembership_Mapping

The mapping of a ValueType is identical to the mapping of a DataType. Therefore, there is no explicit mapping class for ValueType. However, that hides the information of the mapping of ValueTypes in the transformation specification.

The description of the TimeEvent_Mapping class is a note from the development team instead of a description text.

The description of the ChangeEvent_Mapping class is a note from the development team instead of a description text.

Part properties with AggregationKind::none or shared are mapped to Feature, but should be a PartUsage with isComposite=false.

UML4SysML::Class is currently mapped to OccurrenceDefinition, but should be ItemDefinition.

Property_Mapping maps properties typed by a Class or Interface. The target element should be ItemUsage instead of Feature.

The name of the mapping class is misleading. It creates the impression that it maps all kinds of properties, but it only covers the cases where a Class or Interface types properties. Rename the mapping class to PropertyTypedByClassInterface_Mapping.

The specialized mapping classes ConstraintParameter_Mapping, Port_Mapping, and Part_Mapping should specialize PropertyCommon_Mapping instead of Property_Mapping.

The SysML v1 properties like part property, are concepts, but not stereotypes or metamodel elements. Therefore, they are explicitly covered by a mapping class or are listed in the overview tables.

Add a documentation in section 7.8.4.1 that describes how the different SysML v1 property concepts are mapped to SysML v2.

The OCL for both of the constraints validateDefinitionVariationSpecialization and validateUsageVariationSpecialization is:

isVariation implies
    not ownedSpecialization.specific->exists(isVariation)

These constraints should be checking Specialization::general, not Specialization::specific. In addition, the type of both specific and general is Type, which doesn't have an isVariation property. Only Definition and Usage types have such a property.

The table headers state that the rows list SysML v1 and v2 concepts. Actually, they only list stereotype and metamodel elements but not all the concepts. For example, the part property is not listed because it is not a SysML v1 stereotype but only a concept.

In example "Part performs a reference action (action1) that reference subsets another action (action3)" replace «perform action» action1 with «perform» action2, and «action» action3 : Action3 with «action» action2 : Action2, and adapt the textual notation accordingly. This also makes it consistent with the preceding example.

The descriptions in 8.3.16.9 (ForLoopActionUsage) and 8.3.16.18 (WhileLoopsActionusage) refer to "bodyClause", but in Figure 28 (Structured Control Actions) the association end for this (presumably) is called "bodyAction".

Example "Subsetting" is missing specification of the perform action action1 : Action1 that is shown as inherited in the graphical notation. Add part def Part1 in textual notation from preceding example "Usage Definition".

The approved resolution for issue SYSML2-180 uses the mapping class GenericToItemUsage_Mapping which does not exist. It seems that it was overseen to add the creation of the mapping class to the revised text of the resolution.

The generic mapping class GenericToItemDefinition_Mapping specializes GenericToDefinition_Mapping. However, it should specialize GenericToOccurrenceDefinition_Mapping which is a subclass of GenericToDefinition_Mapping as well as ItemDefinition specializes OccurrenceDefinition.

In example "Binding Connection" «ref part» part4R should use the graphical notation as specified in the graphical BNF in subclause 8.2.3.11.

In example "Interface as Node" remove arrow heads from the nested connections, and move arrow head between pa and pb to end of line, add message of item1:Item1 from pa to pb to the interface2 usage in the textual notation. Also add open curly bracket directly after interface2, and closing curly bracket after the ellipsis.

In example "Variants Compartment" textual notation should include part def PartDef1, and item def ItemDef1, and also part1 : PartDef1 and item1 : ItemDef1.

In example "Flow as Node" check whether flow from source :> action1.item1 should be reference subsetting? Add keyword from to the nested flows.

The production for <SourceSuccessionMember > has "+" and it should be "+="

SourceSuccessionMember : FeatureMembership =
'then' ownedRelatedElement + SourceSuccession

The production for <SourceEndMember> has "+" and it should be "+="

SourceEndMember : EndFeatureMembership =
ownedRelatedElement + SourceEnd

Prior error report on this production can be replaced with this error report.

The issue is with the production:

FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping

The correct conjugate nonterminal should be <ConjugatedPortTyping>

The current specification:

SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement + SourceSuccession

SourceSuccession : SuccessionAsUsage =
    ownedRelationship += SourceEndMember

    SourceEndMember : EndFeatureMembership =
ownedRelatedElement + SourceEnd

is incorrect. It should be:

SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement += SourceSuccession

SourceSuccession : SuccessionAsUsage =
    ownedRelationship += SourceEndMember

    SourceEndMember : EndFeatureMembership =
ownedRelatedElement += SourceEnd

The option for <PrefixComment> has been deprecated, but is still an option for AnnotatingElement. Remove PrefixComment.

AnnotatingElement =
  Comment
| PrefixComment
| Documentation
| TextualRepresentation
| MetadataUsage

In the production:

FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping

There is no corresponding production for the non-terminal <ConjugatePortTyping>.
<ConjugatedPortDefinitionMember> or <ConjugatedPortDefinition> may be correct for <FeatureTyping>.

Sections 7.7.4 - 7.7.14 and Section 7.8.5 should contain the introductory sentence:

This chapter lists all mapping specifications of <namespace> model elements.

For example, as in Section 7.7.3:

This chapter lists all mapping specifications of UML4SysML::Activities model elements.

The sentence "The justifications for the elements without mapping are given in view link does not exist" in the State Machines overview sentence does not make sense and should be removed.

In the textual notation grammar, RequirementConstraintUsage produces a ConstraintUsage, but the first alternative in the production allows the ConstraintUsage to have a RequirementBody. The RequirementBody production allows kinds of declarations (such as subjects and actors) that are not valid in the body of a ConstraintUsage (because of validation constraints such as validateSubjectMembershipOwningType, validateActorMembershipOwningType, etc.). There is no point in syntactically allowing owned members that are then invalid, so the first alternative in RequirementConstraintUsage should have a CalculationBody (like the second alternative) rather than a RequirementBody.