In subclause 8.2.3.13 productions for n-ary ConnectionDefinition should be added, similar to the existing production n-ary-connection for n-ary ConnectionUsage.

An n-ary ConnectionDefinition example is given in 7.13.1 Table 11 in row "Connection Definition (n-ary with 3 ends)", like so:

The fourth and sixth rows of "Table 16. States – Representative Notation" each give an example of a transition statement that contains both an if statement and an accept statement, with the accept before the if.

...
transition
   first state1
   accept trigger1
   if guard1
...

However, page 110 and the subsequent examples seem to contradict this:

A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The

accepter action for a transition usage is placed after the guard expression and notated using the accept keyword,
with its payload and receiver parameters specified exactly as discussed in 7.16.8 .

If an accept before an if has a different meaning than an if before accept, the specification document does not make this obvious.
The Jupyter Kernel in release 2024-05 of the SysML-v2-Release repository treats an if before an accept as a syntax error.

On one hand abstract syntax chapters for the transitions between states stipulate (Figure 32 in 8.3.17.1@page316, text in 8.3.17.9@page325)
that transition can have multiple triggers, multiple guards and multiple effects
by specifying multiplicities [0..*] for TransitionUsage::triggerAction, TransitionUsage::guardExpression, TransitionUsage::effectAction

On the other hand, semantics and textual syntax chapters for the transitions between states stipulate (8.4.13.3@page424, 8.2.2.17.3@page178)
that transition can have at most one of each trigger, guard and effect
by stating:
"A TransitionUsage is parsed as having the following ownedMemberships
....
Zero to three TransitionFeatureMemberships for up to one each of a triggerAction, guardExpression, and effectAction."

and by using "?" marks (which has a meaning of [0..1] multiplicity) in the BNF
"TransitionUsage =
...
ownedRelationship += TriggerActionMember )?
( ownedRelationship += GuardExpressionMember )?
( ownedRelationship += EffectBehaviorMember )?"

-----------------------
This contradiction should be resolved in one direction or another - by stipulating either [0..1] or [0..*] everywhere.

We suggest that the variant with singular multiplicity be adopted as this seems to be closer to the original intent of standard builders.
This was also the convention of previous standards (UML)

Therefore the abstract syntax chapters - Figure 32 in chapter 8.3.17.1@page316, and specification in chapter 8.3.17.9@page325 -
should be updated with multiplicity [0..1] for the aforementioned 3 fields.

According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.

The resolutions by the KerML FTF to the following issues make restrictions to the functionality of imports in KerML and hence, by reference, in SysML, also:

• KERML_-73 Disallow public imports at root level
• KERML_-74 Make imports private by default
• KERML_-75 Restrict the functionality of recursive import

The discussion of imports in Clause 7 Language Description need to be updated to reflect these changes (particularly in 7.5.3 Imports). In addition, adopting the requirement to always show visibility of imports in the concrete syntax, consistent with KERML_-74, requires changes in

• 8.2.2.5.1 Packages (textual notation)
• 8.2.3.5 Namespaces and Packages Graphical Notation
• 8.3.5 Namespaces and Packages Abstract Syntax, Figure 5 Namespaces

The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.

However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.

in SysML v1 there is a concept of Complete in terms of Specialization of a GeneralizationSet... that concept seems to be missing in SysML v2

a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2

in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2

in SysMLv1 for an ElementImport one can supply an Alias... That seems to be missing in SysMLv2

In the Geometry Domain Library model ShapeItems, in the item definitions CircularDisc, Sphere, CircularCone and CircularCylinder, the radius feature is bound to semiMajorAxis (or semiAxis1 for Sphere). However, because of the constraint featureValueOverriding, this means that the radius features cannot be re-bound to specific values in user-model usages of these definitions, as would be expected. (Note that this can only be seen in the ShapeItems.sysml file, not in the description in the specification document.)

The coexistence of both the "GenericTo*_Mapping" classes and the Initializer classes generates a significant number of redundancies in the model, and make it harder to understand and to maintain.

More specifically it makes the management of redefinitions much more complex with a very negative impact on the clarity of the specification.

In order to fix that, all the GenericTo*_Mapping classes shall be removed and replaced par their Initializer class equivalent in an appropriate way.

In clause 8.2.3.25 view-frame is specified as a box with sharp corners and a UML / SysML v1 style name compartment.
Since views are usages, their notation should use rounded corners. Also, the '«view»' metaclass name is missing from the graphical symbol.

Affected view examples in the representative graphical notation tables in clause 7.25.5 table 24 should be made consistent with the graphical BNF specification.

Name textual expressions in GBNF for definition and usage names, exclude various characteristics such as specializations, redefinitions multiplicity etc.
Name expressions denoted definition-name-with-alias and usage-name-with-alias in GBNF, should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.

In the following example:

enum def Enum2 :> ScalarValues::Integer {a=1; b=2;}
attribute x1 : Enum2 = Enum2::a;
attribute x2 : Enum2 = 1;
attribute x3 : Enum2 = 42;

x3 is invalid, but currently, there is no validation for it.

Mr. Ed Seidewitz wrote:
x3 is semantically invalid, since 42 is not a legal value for Enum2, but there is currently no static validation check for it. This cannot be checked statically in general, because the bound value could be any expression returning an Integer, the value of which may not be determinable without doing a complete execution/evaluation of the model (we don’t currently have a general way to report “runtime” semantic errors like this, other than that the model will be formally “unsatisfiable”). It might be possible to add a validation constraint for the case in which the both the enumerated values and the bound value in the attribute usage are model-level evaluable expressions (which would catch the case of your x3), though the OCL could be a bit complicated. If you think it is worth it, you could file a SysML v2 Jira issue for this, though it probably not be addressed in the FTF (though we could possibly address it on the KerML side when resolving KERML_-245 to add enumeration syntax to KerML).

Current GBNF uses the textual notation to represent state entry/do/exit actions within a "state actions" compartment.
This does not allow to describe state actions in a graphical way and also requires the graphical modeler to use more extended textual syntax.

The description of message declarations in 7.13.6 Flow Connection Usages and Messages is incorrect. It states that a message declaration "may or may not include identification of source and target related features. If they are included, then they follow the payload specification (if any), with the source related feature identified after the keyword from, followed by the target related feature after the keyword to." However, the from and to features of a message are not the related features of the message as a flow connection usage. Rather, they are the values of the sourceEvent and targetEvent parameters of the MessageConnection (see parsing in 8.2.2.13.4 Message and Flow Connections and semantics in 8.4.9.6 Flow Connection Usages).

In light of this, the message declaration example in 7.13.6 is also incorrect, as is the textual notation for the first "Messages" example in Table 11 Connections – Representative Notation (showing a message between ports). However, the graphical notation in this example seems to be acceptable, as are both the graphical and textual notations in the second "Message" example (showing a message on a sequence diagram).

1. In 7.25.1 Views and Viewpoints Overview, Table 23. Views and Viewpoints – Representative Notation, the example for "Expose" renders the expose relationship using a dashed arrow. However, in 8.2.3.25 Views and Viewpoints Graphical Notation, the graphical BNF production expose-relationship shows the arrow as being solid.
2. An expose relationship is a kind of import and, as such, can expose a single membership or the content of a namespace, and can optionally be recursive. The textual BNF production Expose in 8.2.2.25.2 View Usages allows all these options, as does the graphical BNF production expose-compartment-element (for showing an expose declaration in a compartment) in 8.2.3.25 Views and Viewpoints Graphical Notation. However, the graphical graphical BNF production expose-relationship does not.
3. The textual BNF production Expose allows a VisibilityIndicator on an expose declaration, as does the graphical BNF production expose-compartment-element. However, the graphical BNF production expose-relationship does not.

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

The KerML specification contains guidance for tooling to highlight keywords in concrete textual notation. KerML subclause 8.2.2.6 specifically says:

Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange).

A similar statement, modified for SysML, should be added, probably as a last paragraph under subclause 8.2.2.1.2, including a cross-reference to KerML. For SysML the same guidance applies to textual snippets used in the Graphical Notation.

In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.

The following example appears in 7.8.2 Enumeration Definitions and Usages:

enum def ConditionColor { red; green; yellow; } 
attribute def ConditionLevel {
    attribute color : ConditionColor; 
}
enum def RiskLevel :> ConditionLevel {
    enum low { color = ConditionColor::green; } 
    enum medium { color = ConditionColor::yellow; } 
    enum high { color = ConditionColor::red; }
}

This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.

In 8.3.17.6 StateUsage:

1. The constraint checkStateUsageExclusiveStateSpecialization has the description

   A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.

2. The constraint checkStateUsageSubstateSpecialization has the description

   A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).

3. The operation isSubstateUsage used in the above constraints has the description

   Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.

   However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit actions).

According to the SysML abstract syntax (8.3.17.9 TransitionUsage), the source and target of a TransitionUsage must be ActionUsages. However, the textual notation (8.2.2.17.3 Transition Usages) allows sources and targets to be feature chains, which are parsed as a KerML Feature with FeatureChaining relationships to the chained Features, which are not ActionUsages.

In the SysML Specification, in non-normative Language Description subclause 7.6.3 Usages, it describes several conditions that, if meet, require a usage to have default multiplicity 1..1. However, there is no formal specification of this in the normative Clause 8 Metamodel.

A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.

A state with several regions should be mapped to a parallel state.

1. In 8.3.6.4 Usage, the name of valideaUsageVariationIsAbstract should be validateUsageVariationIsAbstract.

GBNF and notation tables only cover a generic "loop action" which is not aligned with the textual syntax that has 3 specific structured actions:

• while loop action
• for loop action
• if/else action

Each one of the above has a specific textual syntax, that the graphical syntax should align with, to enable proper graphical modeling of actions.

The notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
Graphical Examples need to align with corresponding text examples.

The InitialState should be mapped to an empty ActionUsage owned by a StateSubactionMembership relationship.

The graphical notation makes use of enclosing guillemets to mark up presentation of the metaclass as well as possible metaproperties and metamodel extensions of a model element (i.e., their mapping to the SysML abstract syntax or metamodel). However, there are inconsistencies in their application. The following graphical BNF productions are affected:

• -name-compartment productions,
• -edge and -relationship productions,
• productions including user-defined keywords that extend the metamodel.

Currently, metaproperties of a metaclass are treated in different ways. E.g. in a -name-compartment the isAbstract metaproperty is presented as a leading '«abstract»' literal with its own guillemets, while the isReference metaproperty is included in the main metaclass presentation, e.g., '«ref part»'.

A single, consistent rule should be established for all graphical BNF productions that concern presentation of metamodel information.