The ontological underpinning of KerML (and therefore SysML v2) is based on the Open World Assumption. However, most system model practitioners and model users have an expectation that the Closed World Assumption applies to their system models. This manifests in (at least) two ways:

1) The common expectation is that types will be statically checked and enforced. E.g., if one provides an item of type X to a port that expects an input of type Y, it is not expected that this would be a semantically valid model unless X is a specialization of Y.
2) The common expectation is that queries will return results based only on what has been explicitly specified in the model. E.g., if one queries the model for all parts that have an attribute of type Z, it is not expected to return in the query's results parts that do not have attributes of type Z (or specializations of Z) explicitly specified. OWA leaves open the possibility that these parts may have such attributes that have not yet been specified, but users will almost never want these to be included in queries.

Recommendations:
1. The specification should explicitly clarify the implications of the KerML ontological foundation on type checking and queries to model builders, model users, and tool vendors will have consistent understanding and expectations.
2. The specification should provide a standard means of enabling model builders and model users to specify that they want to impose Closed World Assumption semantics on type checking and queries. This may include distinguishing between warnings that are based on KerML OWA underpinnings and warnings that are not. Ideally, CWA should be the default.
3. Implications for the System Modeling API & Services specification should be considered, particularly as it relates to the interpretation of queries. Requiring CWA be applied to queries may be a setting that is more appropriate at the query level rather than at the model level.
4. It is possible that model builders or users may want strict type checking and OWA queries, or loose type checking and CWA queries, so it may be necessary to decouple settings for type checking and queries.

In 7.16.5 Conditional Successions, in the second paragraph, it states:

Further, the keyword else may be used in place of a guard expression to indicate a succession to be taken if the guards evaluate to false on all of an immediately preceding set of conditional successions.

In 8.2.2.16.7, a conditional succession with the else keyword is parsed as a TransitionUsage that simply does not have a guard condition:

DefaultTargetSuccession : TransitionUsage =
    'else' ownedRelationship += TransitionSuccessionMember

However, the semantics of such a TransitionUsage would seem to be that it can be taken unconditionally, not that it can only be taken if preceding conditional successions have guards that evaluate to false. The else case is not mentioned at all in 8.4.12.3 Decision Transition Usages, which covers the semantics of conditional successions.

There are several places in the specification of SysMLv2.0, that prescribe nested features subsetting from specialized library features.
As an example, spec prescribes that parts inside other parts or part definitions be specialized (directly or indirectly) from Items::subparts feature. Analogous prescriptions exist for actions in actions etc.
Now, if the parent of the part (usage or def) is specialized from some other concept, which has a redefinition of such a specialized library feature, it follows (from normal redefinition and subsetting semantics) that these implied specializations should be adjusted to point to the redefined feature.
This is not explicitly formulated in the spec (even though it is implied) and the pilot implementation (which has aspirations to be turned into reference implementation) does not behave as described above.
Thus:
1) spec should beget clarification of this case explaining expected behavior.
2) reference implementation should behave as described.
3) A test case in the conformance WG should check this.
Example:
/**** Some domain library - e.g. UAF *****/
part def SpecialType;

part def SpecializedDomainConcept

/**** User model ******/

part def UsersConceptFromSpecDomain : SpecializedDomainConcept

/*
The current behavior of reference implementation is that userSubpart1, userSubpart2 are subsetting (implied) Item::subparts.
The expectation is that userSubpart1, userSubpart2 shall be subsetting (implied) SpecializedDomainConcept::specializedSubparts and thus beget the type SpecialType
*/

The specification does not specify a graphical notation for the cross-subsetting. The textual notation is specified with keyword "crosses" and short-hand syntax "=>".

checkInvocationExpressionDefaultValueBindingConnector has no OCL

checkConstructorExpressionResultDefaultValueBindingConnector has no OCL

An example that also show successions and time constraints.

in clause 7.16 table 14, the example sequence diagram does not match the textual model across as it does not refer to the events.
The graphical notation needs to add the event references using proxy connection points on the lifelines.

Lifeline elements need to be included within the lifeline itself, with connector segments above and below, and occurrences of * within the lifeline, similar to boundary elements.

This is done with cross subsetting, which is a special kind of subsetting
relationship specified using the keyword crossing or the symbol =>.

replace the work crossing with crosses

No Abstracts shown in Metamodel... I am assuming one cannot create an Element... yet it is not shown as italicized in the
metamodel... that would be helpful if you had that in the metamodels

Performed By
Compartment is empty

checkCalculationUsageSubcalculationSpecialization has no definition

it says "Further, the keyword else may be used in place of a guard expression" but it needs to add
that may be used in palce of a guard and following then

because the else replaces the then... and nowhere in the spec does it say you can remove the then.... yet that is in the examples

The current SysML metamodel defines use cases as specializations of behavioral elements—effectively treating them as calculations or executable functions. This characterization is semantically inconsistent with the foundational role of use cases in systems modeling. Use cases are not behaviors the system performs internally; rather, they represent contracts or agreements between external actors and the system, specifying what the system is expected to do in response to a stimulus. Modeling use cases as executable behaviors introduces a category error into the metamodel and risks conflating external interactions with internal mechanisms.
Use cases, by their very nature, are interaction scenarios. They do not define how a result is computed or executed, but instead describe what result is expected when a particular actor engages the system in a defined way. Their semantics are declarative and externally visible; they are about outcomes, not procedures. As such, the current inheritance from computational behavior types (such as Function or Behavior) is conceptually incorrect. This structural alignment misleads modelers and tool developers into treating use cases as execution artifacts, which they are not.
If the metamodel insists that use cases must derive from a parent behavioral concept, a more accurate—though still imperfect—choice would be to inherit from a construct akin to a state transition. This would at least preserve the idea that use cases mark a change in the system’s externally observable state as a result of actor interaction. Even so, this remains a second-best solution, as it still imposes a behavioral framing on what should be a scenario-based modeling construct.
The preferred and semantically coherent approach is to model use cases as a distinct first-class metamodel element, such as a Scenario. This new metaclass should stand apart from behavioral execution elements and focus solely on external intent, interaction structure, and resulting system obligations. Two clear examples of such Scenario constructs would be Use Cases and Acceptance Test Scripts. Doing so would reinforce the modeling clarity that use cases are not descriptions of how the system behaves internally, but agreements about what the system must do when engaged from the outside.
Separating use cases from procedural behavior elements also promotes stronger model validation and traceability. It enables more accurate conformance checking between actor expectations and system behavior without enforcing implementation-specific logic. This adjustment to the metamodel aligns better with the practical and pedagogical use of use cases in systems engineering and eliminates the conceptual mismatch that currently exists.
In summary, the treatment of use cases as calculations within the SysML metamodel introduces a fundamental misalignment between semantics and structure. Reframing use cases as scenario-based constructs—independent from executable behaviors—restores conceptual clarity and reinforces the integrity of the modeling language. This change would provide immediate benefit to the precision, usability, and future extensibility of SysML.

subject vehicle : Vehicle {
...
then event occurrence startsDrive [1];
then event occurrence endsDrive [1];

should be

subject vehicle : Vehicle {
...
then event occurrence drives [1];

to make
then message of Drive from vehicle.drives to environment.vehicleDrives;

correct

In 7.24.1 Use Cases Overview, in the third paragraph, it states:

The subject of the included use case is the same as the subject of the containing use case...

In 7.24.3 Include Use Case Usages, in the third paragraph, it also states:

The subject of an included use case usage is bound by default to the subject of its containing use case definition or usage.

However, there is no semantic constraint in the abstract syntax to enforce this.

The doc descriptions of MergeAction, DecisionAction, JoinAction and ForkAction use "succession connector". This should be replaced with "succession connection" (4 times).

Standard library ISQMechanics.sysml contains a declaration of torque as a scalar quantity to represent torque magnitude, but the related torque vector quantity is missing.

A torque vector quantity and associated coordinate frame should be added using the same pattern as for other vector quantities.

Note: This issue was flagged in "SysML v2 Release" Google Group at https://groups.google.com/g/sysml-v2-release/c/w7ZbFZ9d-e0/m/yTF8oyb6AwAJ .

Tables 25 and 34 in clauses 7.26.5 and 9.2.20.1 respectively have inconsistent descriptions of standard views. Table 34 is the authoritative source for the standard view definitions. The first column of Table 25 will need to be updated to be consistent with Table 34.

As part of the Users WG in coordination with Execution WG, we have determined that successions from the "start" of a state or the "entryAction" of the state can cause confusion for many users. As such, we want to "deprecate" this usage in favor of requiring an explicit state transition from "start" to the first subState.

We will need to update all of our relevant graphical and textual examples shown in the spec to demonstrate this preferred approach and remove the previous approach.

Models using successions from "start" or "entryAction" will remain valid but will not be the preferred method. We will want to indicate that support for such may be removed in some future version, subject to a discussion around what the deprecation policy should be.

In 'Table 3. Packages - Representative Notation', there is a 'Package with owned package' graphical example where the owned package is displayed but as text rather than as a node.
Should this example be removed, or should the 'general-view' element be updated to include node representation in text?

There is an inconsistency between Table 3. Packages - Representative Notation (specifically the Package with imported package (nested notation) element) and the Graphical BNF. In section 8.2.3.5 Namespaces and Packages Graphical Notation, it is specified that the Package shape should not display any keywords above its name when it is imported. However, in the table example, the visibility indicator keyword is visible.

The following cosmetic changes are needed for some graphical examples displayed in the tables:

• Table 6. Enumerations - Representative Notation table. The Enumeration Definition element - The enumeration def keyword should be corrected to enum def.
• Table 7. Occurrences - Representative Notation table. The Snapshots compartment element - the semicolons after each snapshot value should be removed.
• Table 9. Parts - Representative Notation table. The Part with Graphical Compartment showing a standard interconnection view of part1 element - the '=' symbol is missing from the bind connections.
• Table 14. Actions - Representative Notation table. The Perform Actions Swimlanes element - the succession connection between 'action2' and 'action3' should be a dashed line instead of a solid one.

There is an inconsistency in the Table 4. Definition and Usage - Representative Notation table (specifically the Name Compartment - Definition element).
In this example, the abstract keyword is omitted from the symbol keyword («part def»), whereas in other examples, the abstract keyword is displayed when usage/definition is shown as a shape.
Does this imply that additional property keywords are optional for display in the shape?

In section 8.2.3 of the Graphical Notation for packages, it is stated that no keyword should be displayed before the name.
Our concern is that without a keyword, it will not be possible to differentiate a library package from a standard package within the diagram.

There is an inconsistency between the examples in the following tables and the Graphical BNF:

• Table 11. Connections - Representative Notation (specifically the 'Flow' element).
• Table 12. Interfaces - Representative Notation (specifically the 'Interface as Node (with flow)' element).

In these examples:

• Parameters with specified directions do not display arrows on the parameters located on the border, despite the Graphical BNF (8.2.3.16 Actions Graphical Notation) not indicating that arrows are optional in this context.
• Similarly, in the 'Interface as Node (with flow)' example, port features with specified directions also lack arrows on the ports.

There is an inconsistency between the examples in the following tables and the Graphical BNF:

• Table 11. Connections - Representative Notation (specifically the Connection, Nested Connection, Proxy Connection, Flow, Message elements)
• Table 12. Interfaces - Representative Notation (specifically the Interface, Interface as Node elements)
• Table 16. States - Representative Notation (specifically the State with Graphical Compartment with standard state transition view for sequential states)
• Table 22. Use Cases - Representative Notation (specifically the Use Case Graphical Compartment element)

In these examples, some shapes are missing the symbol keyword within «». According to the Graphical BNF, these keywords do not appear to be optional.

There are inconsistencies between table examples and the Graphical BNF due to compartments being displayed that are not specified in the BNF:

• Table 4. Definition and Usage - Representative Notation table (specifically the Variant Parts Compartment element) - 'variant parts' compartment is not specified
  • In section 8.2.3.6 (Definition and Usage Graphical Notation), only two compartments for displaying variants are specified.
• Table 7. Occurrences - Representative Notation table (specifically the Individuals Compartment (parts) element) - 'individual parts' compartment is not specified.
  • The Graphical BNF (8.2.3.9 Occurrences Graphical Notation) specifies only an "individuals" compartment.
• Table 11. Connections - Representative Notation table (specifically the Flows Compartment element) - 'flows' compartment is not specified, and the graphical example is also not displayed.
• Table 13. Allocations - Representative Notation table (specifically the Allocated Compartment element) - 'allocated' compartment is not specified.
  • In the Graphical BNF (section 8.2.3.15 Allocations Graphical Notation), only one compartment, allocations, is specified.
• Table 16. States - Representative Notation table (specifically the Exhibit States Compartment and Exhibited By Compartment elements) - the 'exhibits' and 'exhibited by' compartments are not specified.
• A Annex: Example Model section in 'Requirements Group vehicleSpecification' view - the 'references' compartment is not specified.
• A Annex: Example Model section in ' Part Definition for FuelTank Referencing Fuel it Stores' view - the 'operator expressions' compartment is not specified.

There is an inconsistency between Table 19. Requirements - Representative Notation (specifically the 'Requirement' element) and the Graphical BNF (section 8.2.3.4).
In the table example, the 'doc' compartment is labeled as 'documentation,' which is incorrect according to the BNF. The label should be 'doc.'

In the following tables, examples display port/parameter labels on the border as being inside the context:

• Table 2. Annotations - Representative Notation table  - 'Annotation-Documentation', 'Annotation-Textual Representation' elements.
• Table 9. Parts - Representative Notation table - 'Part with Ports, Part with Graphical', 'Compartment showing a standard interconnection view of part1.' elements.
• Table 11. Connections - Representative Notation table - 'Proxy Connection', 'Message' elements.
• Table 12. Interfaces - Representative Notation table - 'Interface', 'Interface as Node', 'Interface as Node (with flow)'  elements.
• Table 14. Actions - Representative Notation table - 'Action with Parameters' element.

However, according to the BNF specification (8.2.3.12; 8.2.3.16), labels for ports and parameters on the border should be positioned outside the context.

In Table 4. Definition and Usage - Representative Notation, the 'Name Compartment - Definition (abstract)' element displays the usage as abstract, with its name in italic font. However, other examples with abstract usages/definitions, such as 'Name Compartment - Definition' and 'Name Compartment - Usage (abstract)', do not display their names in italic font.

In Table 16. States - Representative Notation, the "State with entry, do, and exit actions" element includes an 'actions' compartment, where the entry, do, and exit actions are displayed.
However, in the 8.2.3.17 States Graphical Notation section, it is specified that the only compartment permitted to display the entry, do, and exit keywords is named 'states', creating a discrepancy between the table and the section.

Table 13 shows an example of a composite allocation. Part allocation owns an allocation between performed actions.
The graphical notation shows an allocation edge between perform edges, owned by an allocation edge between parts.
It is for sure confusing, and not sure if the textual notation that says

 allocate part1.action1 to part2.action2; 

is correct, provided that action1 and action2 are performed but not owned actions.
Even if technically correct, it would be better to present a clearer and simpler example of composite allocations.

In 7.25.2 the spec says "A view artifact is an individual view usage where the model content is rendered in a compartment of the view usage"
View artifact is italicized so it is presumably significant but I don’t understand the sentence.

In section 7.25.1 on page 137, view artifact is defined thus: “A view artifact is a rendering of information that addresses some aspect of a system or domain of
interest of concern to one or more stakeholders”

There are two row headers which says "Interface". One of these showed more of a general/compartment view (no declared connection), while another shows more of an interfaces view (including a declared connection). Please make the headers more clear regarding what the reader should find.

E.g.:
Interface Usage
Interface with connection

To be more consistent across the section 7 tables in the specification, make the row headers of table 2 unique. From:
Comment
Comment
Documentation
Documentation

to something like:

Comment (stereotype hidden)
Comment (stereotype, name shown)
Documentation
Documentation with Name

In clause 7.16.1, Table 14, example "Action with Parameters", the name "param2 : ItemDef2" of the out parameter on the righthand side should be placed outside the action1 rectangle.

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 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 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 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.

Verified
Requirements
Compartment

is empty need to be filled or removed

Performed By Compartment is empty needs to be removed or filled

In subclause 7.8.1, Table 6 "Enumerations", first example row "Enumeration Definition", the graphical notation has two mistakes: in both enumeration definition symbols the label within guillemets should read «enum def» instead of «enumeration def», as specified in the Graphical BNF per subclause 8.2.3.8.

Add to the row names more detail that indicates that one is part def - part feature membership and one is part - part feature membership.

SysML2 should support both graphical and textual syntax for guards on flows. The graphical and textual syntax should be like the syntax for successions. Ideally, the abstract syntax created by parsing the graphical and textual syntax for guards on flows should be more direct than the approach suggested for translating SysML1 object flows into SysML2 (proposed in Section 7.7.3.3.50 of the SysML v1 to SysML v2 Transformation specification).

In subclause 8.2.3.8 three corrections on graphical BNF productions are needed:

• In production enumeration-def-name-compartment, DefinitionPrefix is too wide and should most likely be replaced with DefinitionExtensionKeyword*.
• In production enumeration-name-compartment, UsagePrefix is too wide and should most likely be replaced with UsageExtensionKeyword*.
• In production enums-compartment-element, el-prefix? UsagePrefix is too wide and should most likely be removed.

Need to add recursive production of swimlanes as part of the swimlane graphical production.

Currently the graphical BNF only allows a flat sequence of swimlanes.
However in case of a hierarchical parts structure, for example, it is desired to represent the parts containment hierarchy using a hierarchy of nested swimlanes. For example a swimlane that represents a vehicle is partitioned into two nested swimlanes for the engine and the transmission.

Clause 9.3.5 describes icon metadata, with the objectives to attach icons to model elements in a graphical/tabular view,
There are two issues here
(1) It is not practical too attach an icon to each individual usage, it is expected that assigning such a metdata to a semantic metadata would imply the icons also on elements referring to the semantic metadata. For example, if a semantic metadata defined for "assembly", any definition or usage "tagged" as assembly is expected to have this icon. The current specification does not address this practical issue.

(2) The graphical notation representative tables anf BNF do not cover how an icon is represented in case an icon is defined

In Table 15 of the Representative Notation Tables, the row labeled Accept and Send Action Flow includes a model fragment that uses a combination of a succession and a binding connection to connect to the input payload parameter of a send action and from the output payload parameter of an accept action. This issue recommends adding another example of a common pattern that replaces the succession and the binding connection with a succession flow.

The current specification presents two issues with compartment definitions:
• The same elements may appear in multiple compartments, even when a more specific compartment is defined (e.g., action and perform action).
• Because keywords are hidden, compartment element keywords cannot be clearly distinguished (for example, perform action looks the same as action).

To address these issues, the following adjustments are proposed. Specific compartments should explicitly exclude overlapping contents:

actions-compartment-contents (page 227)
• exclude perform-actions-compartment-contents (page 227)
use-cases-compartment-contents (page 255)
• exclude include-use-cases-compartment-contents (page 255)
states-compartment-contents (page 238)
• exclude exhibit-states-compartment-contents (page 239)
constraints-compartment-contents (page 243)
• exclude require-constraints-compartment-contents (page 246)
• exclude assume-constraints-compartment-contents (page 246)
• exclude assert-constraints-compartment-contents (page 244)
requirements-compartment-contents (page 246)
• exclude satisfy-requirements-compartment-contents (page 247)
• exclude verifies-compartment-contents (page 253)

Currently, the usage appearance in the ‘parameters’ compartment is defined in the “8.2.3.17 Actions Graphical Notation” chapter as follows:

parameters-compartment-element = el-prefix? FeatureDirection UsageDeclaration ValueOrFlowPart? DefinitionBodyItem*

This is not consistent with other compartments that represent elements which can declare a direction (it includes only the ‘direction’ modifier but omits others), such as items, parts, and attributes:

items-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
attributes-compartment-element = el-prefix? UsagePrefix usage-cp

Currently, the usage appearance in end compartment are declared in “8.2.3.14 Interfaces Graphical Notation” chapter like that:

ends-compartment-element = QualifiedName (’:’ QualifiedName)?

It is not consistent with all other compartments, e.g. parts, ports:

parts-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp
ports-compartment-element = el-prefix? OccurrenceUsagePrefix usage-cp

Currently the BNF requires a separate flow symbol for every flow that transpires over a connection (or an interface).
It is requested to also support a more compact notation, that each flow symbol can represent multiple flow usages specified in a comma separated list.

Subclause 7.27 shows a metadata node attached to a usage with a dotted connector. This is not supported by the GBNF. metadata-feature-annotation-node defined in subclause 8.2.3.27 should be included with the annotation-node production in subclause 8.2.3.4.

Graphical BNF does not allow a metadata compartment.

Annotations and successions are consistently represented with short dashes in both the graphical examples in Clause 7 and the graphical BNF. However, the specification does not consistently depict the dashed lines that are used in dependencies and related relationships.

DEPENDENCIES:
Table 1 "Dependency" - long dashes
Table 1 "Dependency - nary" - medium dashes
8.2.3.3 binary-dependency - short dashes
8.2.3.3 n-ary-dependency-*-link - short dashes

IMPORTS:
Table 3 "Import (recursive) - short dashes
8.2.3.5 import - long dashes

EXPOSE:
Table 24 "Expose" - long dashes
8.2.3.26 expose_r and *-expose-r - short dashes

Recommend the graphical BNF and graphical examples in the tables be made consistent in showing these relationships as having long dashes. This will help users to distinguish these types of relationships from those having short dashes, e.g., successions and annotations, and would be more familiar to users having experience with UML, SysML v1, etc.

1. The perform-actions-swimlanes production does not appear to be used anywhere.
2. The swimlane production only appears to support vertical swimlanes. i.e., with the action flow displayed below the head rather than to the right of it. Horizontal swimlanes should also be supported.
3. There is no production for the <<performer>> keyword in the head of a swimlane. The appropriate production appears to be Usage-name-compartment (which is missing, as was noted in SYSML21-251), but this name should probably be changed to be more specific to this usage, e.g., swimlane-name-compartment or performer-name-compartment to be consistent with the names of other similar productions.
4. The note "Note. All swimlanes are attached to each other on vertical edges and aligned along the top and bottom horizontal edges." in 8.2.3.17 does not appear to be followed by the examples of swimlanes that appear in Table 15.
5. The swimlanes production have squared (right-angled) corners, but rounded corners appear in the examples in Table 15.

The specification does not define how to show filter conditions at an import relationship, and it also does not define a compartment for packages for owned filter conditions.

In the Graphical BNF, the only usages that lack the 'compartment-stack' section are the send and accept action usages. Is this intentional, meaning these actions cannot have compartments?

In section 8.2.3.12 of the Ports Graphical Notation, ports displayed as shapes have only a solid border, whereas ports on the border of another shape may also have a dashed border, as noted:
"Dotted line port productions (references) are only possible for nested ports."
This implies that a nested port can be displayed on another port with a dashed border. However, based on the BNF, the same nested port cannot be displayed with a dashed border when shown as a regular shape.

There is an inconsistency between Table 14. Actions - Representative Notation (specifically the Actions with Control Nodes element) and the Graphical BNF.
In this example, the control nodes (join, fork, decision, and merge nodes) have names displayed in the diagram. However, the Graphical BNF (section 8.2.3.16 Actions Graphical Notation) does not specify that names can be displayed for these nodes.

There is an inconsistency between the table examples and the Graphical BNF (section 8.2.3.13):

• Table 11. Connections - Representative Notation: 'Flow as Node' element
• Table 12. Interfaces - Representative Notation: 'Interface as Node' and 'Interface as Node (with flow)' elements

In these examples, the line connecting the connector as a path and as a shape is represented with dashes. However, in the BNF, this line is specified as dotted.

There are inconsistencies between the examples in Table 12. Interfaces - Representative Notation (specifically the 'Interface as Node' and 'Interface as Node (with flow)' elements) and the Graphical BNF (section 8.2.3.14).
In these examples, nested shapes are displayed without a compartment. However, the BNF does not specify that a general view or interconnection view is applicable for interface usage.

There is an inconsistency between Table 14. Actions - Representative Notation (specifically the 'Parameters Compartment' element) and the Graphical BNF.
In the table, the 'return' keyword is displayed before the name of the 'param4' feature. However, the 'return' keyword is specified under the 'ReturnParameterMember' element, which is not included in the 'parameters-compartment-element' specification. As a result, based on the BNF, the 'return' keyword should not appear in the parameters compartment.

There is an inconsistency between Table 18. Constraints - Representative Notation (specifically the 'Constraints Compartment' element) and the Graphical BNF (section 8.2.3.19).
In the example, the keywords 'require', 'assume', and 'assert' are displayed before the constraint name. These keywords are only defined under 'AssertConstraintUsage' (for 'assert') and 'RequirementKind' (for 'assume' and 'require'). However, these elements are not included within the 'constraints-usage-compartment-element' specification.

There are several examples where the 'doc' keyword is displayed in the 'objective' compartment:

• Table 20. Analysis Cases - Representative Notation
• Table 21. Verification Cases - Representative Notation
• Table 22. Use Cases - Representative Notation

However, upon reviewing the specification for the 'objective' compartment, neither the 'doc' keyword nor the documentation text body is visible in any of the specified elements.

There is an inconsistency between Table 23. Views and Viewpoints - Representative Notation (specifically the 'Frame' element) and the Graphical BNF in section 8.2.3.20.
In the table, the 'frame' relationship connects a viewpoint to concern usages. However, the BNF specification for the 'frame' relationship does not include viewpoint usage as one of the possible relationship ends, as it has 'subject-actors-stakeholders-node' for one end and 'concern' for another.
The 'subject-actors-stakeholders-node' includes:

• requirements.
• analysis usage/def.
• verification usage/def.
• use case usage/def.

Additional properties that are specified under UsagePrefix/OccurrencePrefix element are missing for these usages inside the «» :

• timeslices.
• snapshot.
• calculation usage - changes that were described in SYSML2_-197 ticket were not done - the old occurence-name-prefix and ref are not removed.
• item usage - changes that were described in SYSML2_-197 ticket were not done - the old basic-name-prefix and ref are not removed.

The Swimlane element is described in the specification as containing two elements: Usage-name-compartment and action-flow-node. However, several issues arise with this definition:
The issues regarding the Swimlane:

1. The Usage-name-compartment is not specified.
   • The specification does not provide any details or clarification for the Usage-name-compartment element, leaving its definition ambiguous.
2. Incomplete action-flow-node Definition
   • The definition of action-flow-node excludes relationships and action usages.
   • It currently includes only the following:

     action-flow-node =
      start-node
      | done-node
      | fork-node
      | join-node
      | decision-node
      | merge-node
      | send-action-node
      | accept-action-node
      | while-loop-action-node
      | for-loop-action-node
      | if-else-action-node
      | assign-action-node
     

3. Missing Compartment Declaration in Swimlane Specification
   • Examples in Table 14. Actions - Representative Notation display a compartment named perform actions within the Swimlane.
   • The specification, however, does not declare that such a compartment can be displayed, leading to inconsistency

In the Table 19. Requirements - Representative Notation table in the Satisfy Requirements Compartment element a lot of information is displayed:

• requirement that is satisfied.
• nested requirement with their nested features with values.
  However in the 8.2.3.20 Requirements Graphical Notation section, it is not clear what information should be displayed in the satisfy requirement compartment.
  it looks that just text should be added:

  satisfy-requirements-compartment-contents = text-block
  

In the graphical BNF the short usage name notations are not specified as well duplicated usage keywords are possible. For these usages, the issues occurs:

• perform action -> perform;
  • the usage with 'perform' keyword is displayed in Table 9. Parts.
• exhibit state -> exhibit;
  • exhibit-state-name-compartment = '«exhibit-state»' state-name-compartment - as well based on the specification the keywords could be «exhibit-state» «state», as the state-name-compartment is used.
• assert constraint -> constraint
  • assert-constraint-name-compartment = '«assert constraint»' constraint-name-compartment - as well based on the specification the keywords could be «assert constraint» «constraint», as the constraint-name-compartment is used.
  • the same issue could be for require constraint and assume constraint but they are not specified as a node shape in the 8.2.3.19 Constraints Graphical Notation section.
• satisfy requirement -> satisfy
  • the usage with satisfy keyword is displayed in Table 19. Requirements
  • satisfy-requirement-name-compartment = '«satisfy requirement»' requirement-name-compartment - as well based on the specification the keywords could be «satisfy requirement» «requirement», as the requirement-name-compartment is used.
• the same issue could be for frame concern but it is not specified as a node shape in the 8.2.3.20 Requirements Graphical Notation section.
• include use case -> include
  • include-use-case-name-compartment = '«include use case»' requirement-name-compartment - as well based on the specification the keywords could be «include use case» «requirement», as the requirement-name-compartment is used.

In the Table 25. Metadata - Representative Notation (Chapter 7.26.1 , page 151) table there is an element that specifies the metadata compartment, however, this compartment is not specified in the Graphical BNF.

For ports and parameters on border, connectors and transitions name label there is no indication to display an inheritance symbol.
The el-prefix is not indicated in none of these element specifications.

• Ports and parameters on border labels are specified as QualifiedName (‘:’ QualifiedName)*;
• Connectors labels are specified as UsageDeclaration? / UsageDeclaration? ('of' FlowPayloadFeatureMember)? | FlowPayloadFeatureMember / UsageDeclaration? ('of' ItemFeatureMember)? | ItemFeatureMember;
• Transitions label is specified as trigger-expression/ActionUsage;

proxy connection in sequence views should be contextualized on lifelines.
Right now they just float as nodes.

These issues reported by Dovile.ZIAUKIENE from Dassault.
See 2 attachments.
1. Name compartment of a package does not support guilements modifiers

• a GBNF issue

2. Unowned member alias notation

• looks like a notation tables issue

In clause 8.2.3.5 graphical BNF production relationship-name has an incorrect body of comma-separated terminals.

It should use the pipe symbol as a separator instead of comma, i.e.:

relationship-name = 'defines' | 'defined by' | 'specializes' | 'specialized by' | 'connect to'
    | 'subsets' | 'subsetted by' | 'performs' | 'performed by' | 'allocated' | 'allocated to'
    | 'satisfy' | 'satisfied by'

In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent.

• Besides pure "require ConstraintUsage" statements a "require constraints" compartment may also contain "require RequirementUsage" statements. Furthermore, a "require RequirementUsage" has the same semantics as a composite RequirementUsage owned by a containing RequirementUsage (see explanation in subclause 7.20.2). Therefore a better compartment name is possibly "requires".
• Similarly besides pure "assume ConstraintUsage" statement an "assume constraints" compartment may also contain "assume RequirementUsage" statements. Therefore a better compartment name is possibly "assumes".

1. The GBNF production for a transition is wrong, it does not account for nodes which are not states (e.g. control nodes)

2. The production for states actions compartment is incorrect, the compartment name is currently named "states" while it should be named "state actions".

Currently proxy connection points are supported by GBNF only for interconnection, action-flow, and sequence views. They should also be applicable in state-flow and possibly other views such as case and general views for additional usage nodes.

name compartment productions for send and accept actions are not reusing the textual productions for usage declarations and misaligned with the rest of the graphical BNF

Currently two conventions are used for graphical action names e.g. send action vs. assign, so issue is whether the action postfix is used or not. Note that the textual notation does not use the postfix action. Regardless, this needs to be aligned along the GBNF and representative notation tables.

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!

State shall be able to have proxy nodes on their boundaries. Currently not covered by the GBNF

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 graphical BNF production should be added that specifies that it is mandatory to include the applicable user-defined keyword in the notation for a library extension element.

A graphical BNF production should be added that specifies that keywords may optionally be included on edges.

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.

Events and event occurrences are supported by the textual syntax, but not by the graphical syntax.
It is also not mentioned in the representative notation tables

Actor and subject are parameters of a use case (and also requirement in case of subject). The current notation suggests symbols completely outside the contour of the use case/requirements linked by a line segment. This is different from V1 where actors and subjects were not parameters. Ultimately the modeler is interested to see the binding of those parameters being the concrete occurrences standing for them. The parameter bindings can be graphically represented by binding connections to those external symbols. Would be more effective to treat those predefined parameters using on contour symbols like ports and parameters and bind to those.

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