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.

This table has two rows where the Element Column states Enums Compartment. Recommend adding information to the row titles to indicate what aspect of the compartment is important. E.g., Enums Compartment (enumeration usage names) and Enums Compartment (enumeration values). Alternatively, combine these into one row.

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, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

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.

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

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!

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.

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

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.

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

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

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.

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.

It's likely that OrderedContainer is supposed to specialized Container, such that orderedContent can redefine content.

abstract part def Container {
  abstract ref content : Base::Anything;
}
part def OrderedContainer {
  // By default, the following is a reference usage.
  orderedContent ordered :>> content;
}

In the following sentence, the word "enumerationDefinition" should be "EnumerationDefinition".

"However, other than when nested in an EnumerationDefinition, an EnumerationUsage is semantically just an AttributeUsage that is required to be typed by exactly one EnumerationDefinition (syntactically enforced by the 1..1 multiplicity of EnumerationUsage::enumerationDefinition, see 8.3.8 )."

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 7.16.1 (Actions Overview), under Sequencing of Actions, 7.16.3 (Control Nodes), and 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 binding 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".

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

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

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

The transformation does not map the Parameter::isStreaming.

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

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

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.

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.