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

(This issue was one of five identified in SYSML21-294 but has been extracted into a new issue since we intend to defer this one to SysML 2.1 but not delay resolution of the other four.)

Nature: request for enhancement (interchange gap). Severity: significant.

The textual notation deliberately omits Element::elementId: text is treated as a projection, and identity as the repository's concern. But the notation is the form engineers version, diff and review, and the Systems Modeling API and Services specification addresses every element by that id. The combination severs round trips: any tool that serializes a model to text and reads it back has lost the correlation with the repository it came from, so a rename – same element, new name – is indistinguishable from a delete plus a create. Implementations are already inventing workarounds (sidecar mapping files, IRI conventions, comment conventions), none of which survive interchange through another conforming tool.

Proposal: standardize identity annotations – either a normative metadata library, or dedicated surface syntax if the taskforce prefers. A minimal library form, implementable today because user-defined metadata is already conforming notation:

standard library package IdentityMetadata {
    metadata def ElementId {
        attribute id : ScalarValues::String;
    }
    metadata def ProjectRef {
        attribute projectId : ScalarValues::String;
        attribute branch : ScalarValues::String[0..1];
        attribute org : ScalarValues::String[0..1];
    }
}

Applied opt-in: @ElementId

on an element pins its repository identity; one @ProjectRef on the root namespace binds the document to a project (branch selecting a version, never contributing to identity). Elements without an annotation keep tool-derived identity, so unannotated models are unaffected and annotation cost is paid only where correlation matters.

Implementation experience: OpenSysML (github.com/Open-MBEE/OpenSysML) implements exactly this shape: the metadata library, a validation pass (duplicate and malformed ids, project-scope conflicts), RDF export keyed by the effective id, and reader re-materialization closing the notation -> RDF -> notation round trip byte-for-byte – all without any specification change, demonstrating that only the standardization of the spelling is missing. Round-trip measurements against a live Flexo MMS repository are maintained in the project's committed interoperability report.

The definition of 'pi' provided in TrigFunctions::pi (KerML) also includes an invariant that specifies PI to 20 significant digits.

However, in SI.sysml where we define 'degree', the conversion factor is listed as:

attribute <'°'> degree : AngularMeasureUnit { :>> unitConversion: ConversionByConvention { :>> referenceUnit = rad; :>> conversionFactor = 1.745329E-02; :>> isExact = false; } } // conversionFactor should become pi/180

It appears that this was intended to be a "TODO" that was never addressed!

Having the conversion factor from degrees to radians only listed to "single precision" will be a severe problem for many engineering applications. We should instead depend on the actual "pi/180" expression as stated in the trailing comment

The current version of the the model of the SysMLv1 to v2 transformation contains a huge number of mapping classes with a high level of redundancy. Those redundancies also affect the OCL code making the overall difficult to understand and to maintain.

This is a major issue both for people that want to implement that transformation and for the RTF team that has to work on it.

As a consequence SysMLv literals generated by the transformation have no value defined

GenericToRelationship_Mapping should provide default rules for

• owningRelatedElement
• isImplied

Since Relationship is now an abstract class, ElementOwnership_Mapping has been made abstract as well. A consequence of this, because it is not a "MainMapping", is that it is not possible to invoke the getMapped operation directly on this mapping class.
However there are many body conditions that still that. They have to be fixed.

You cannot use a conjugated port definition via its short name.

    port def <A1> 'Alpha 1' {
        in item xyz;
    }
    part def ABC {
        port a1 : A1;
    }
    part def XYZ {
        port a1 : ~A1; //This causes an issue.
    }

There do not appear to be any graphical productions to represent the graphical equivalent of the "not satisfy" (or "not satisfy requirement") sets of keywords in the satisfy-requirement-name-compartment and satisfy-edge productions. There should also be examples in the Representative Notation Table for Requirements, Table 20.

There do not appear to be any graphical productions to represent the graphical equivalent of the "assert not" (or "assert not constraint") sets of keywords in the assert-constraint-name-compartment and assert-edge productions. There should also be examples in the Representative Notation Table for Constraints, Table 19.

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.

The constraint checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose owningType is a RequirementDefinition or RequirementUsage specialize RequirementCheck::subrequirements. However, RequirementCheck::subrequirements subsets RequirementCheck::constraints, which is the set of required constraints of the requirement. So it doesn't make sense for a RequirementUsage to specialize subrequirements if it is owned as an assumed constraint.

(Sorry for repeating this issue, because in the former one (https://issues.omg.org/issues/lists/unclassified#issue-59447) I misspelled my email, sry again)

Problem

The published SysML 2.0 document contains an apparent inconsistency between a language-description example in informative Clause 7 and the normative language definitions in Clause 8. Clause 7 states that it is informative, while also stating that it is intended to be precise and consistent with the normative specification. This report therefore asks OMG to reconcile the published example with the normative grammar; it does not treat every sentence in Clause 7 as an independent normative production.

Published OnOff6 example

In Clause 7.18.3, page 122 of formal/26-03-02, the published OnOff6 language-description example contains the following declaration inside a state definition body:

state def OnOff6 {
    port commPort;
    entry; then off;
    state off;
    accept TurnOn via commPort then on;
    accept Abort via commPort then stop;
    state on;
    accept after 5[min] then done;
    action stop terminate;
}

Normative production and state-body dispatch

Clause 8.2.2.17.6, page 183, defines TerminateNode as follows:

TerminateNode : TerminateActionUsage =
    OccurrenceUsagePrefix ActionNodeUsageDeclaration?
    'terminate' ( ownedRelationship += NodeParameterMember )?
    ActionBody

However, Clause 8.2.2.18.1, pages 184-185, defines StateBodyItem without an ActionNode or TerminateNode alternative. The corresponding published 2026-05 Release KEBNF is available at StateBodyItem in SysML-textual-bnf.kebnf and is:

StateBodyItem : Type =
      NonBehaviorBodyItem
    | ( ownedRelationship += SourceSuccessionMember )?
      ownedRelationship += BehaviorUsageMember
      ( ownedRelationship += TargetTransitionUsageMember )*
    | ownedRelationship += TransitionUsageMember
    | ownedRelationship += EntryActionMember
      ( ownedRelationship += EntryTransitionMember )*
    | ownedRelationship += DoActionMember
    | ownedRelationship += ExitActionMember

BehaviorUsageMember can reach ActionUsage, whereas TerminateNode is an alternative of ActionNode, not an alternative of the ActionUsage production. An action body reaches action nodes through ActionBehaviorMember and ActionNodeMember, but StateBodyItem has no corresponding dispatch path. Consequently, the TerminateNode production exists but is unreachable for action stop terminate; in a state body.

Independent implementation evidence

The official SysML v2 Pilot Implementation defines TerminateNode at SysML.xtext TerminateNode, while its StateBodyItem alternatives at SysML.xtext StateBodyItem do not include a general ActionNode or TerminateNode path. The ANTLR grammar generated by daltskin/sysml-v2-grammar at commit 7292dc39983a6d263d14f8f6689de0f3b35db5eb (v2026.05.0) likewise defines terminateNode at SysMLv2Parser.g4 terminateNode, but its stateBodyItem dispatch at SysMLv2Parser.g4 stateBodyItem does not make that production reachable for the OnOff6 declaration. This indicates that the observed problem is not specific to an ANTLR conversion in one downstream project: the published example, the normative textual grammar, and the official executable grammar are not aligned.

Duplicate and related-issue boundary

The closest open issues found during duplicate checking are SYSML21-158, Control nodes missing from textual notation for states, and SYSML21-367, No support for control nodes in Statemachines textual notation. Both currently discuss fork, join, decision, and merge control nodes. TerminateNode is an ActionNode but not a ControlNode, and neither issue mentions terminate actions or OnOff6. They may eventually share a grammar-dispatch resolution, but the concrete inconsistency reported here is not covered by their current descriptions.

Other terminate-related records are distinct: SYSML2_-44 concerns the semantic introduction and mapping of terminate actions; SYSML2_-296 concerns the graphical notation grammar; the closed SYSML2_-487 concerns displaying ordinary action nodes in the graphical stateflow view; SYSML21-28 concerns coordination of Actions::TerminateAction documentation; and SYSML21-635 concerns graphical notation for a terminate parameter. None addresses the textual StateBodyItem reachability of TerminateNode for action stop terminate; in OnOff6.

Requested clarification and correction

Please clarify and correct the relationship between the OnOff6 example, TerminateNode, StateBodyItem, and StateActionUsage so that the published example has an unambiguous, conforming textual parse and an explicitly defined abstract-syntax classification. In particular, please specify whether state bodies are intended to admit this terminate action through StateActionUsage, through a general ActionNode/TerminateNode alternative, or through another production. If the example is not intended to be legal in a state body, please revise the example and the surrounding textual description instead.

As a practical conformance criterion, the resolved specification should make the following minimal example, reduced from the published OnOff6 example, parse without a syntax error or error recovery and should identify the declaration as the intended terminate-action usage:

state def OnOff6 {
    action stop terminate;
}

This issue is reported against the published SysML 2.0 specification. The daltskin/sysml-v2-grammar repository may need a follow-up compatibility or generator patch after the OMG resolution, but the primary request here is for OMG to resolve the specification inconsistency.

Evidence

• SysML 2.0 specification catalog
• SysML 2.0 Language PDF
• SysML v2 Release KEBNF StateBodyItem
• Official terminate-action training example
• Official Pilot TerminateNode
• Official Pilot StateBodyItem
• daltskin terminateNode
• daltskin stateBodyItem

Currently it is not possible to use action control nodes (Fork/Join/Decision/Merge) as sources/targets of a transition in a state definition or usage.

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

In both diagram and tabular representations, nested views are used extensively. For example, a part view might have 3 nested compartment views. All the views, the parent and the nested views, expose the same element with different filters.
Repeating the expose feature again and again may result in an inconsistency, and also very cumbersome.
The need is to have propagation semantics for expose feature (and maybe something more general?) that results in the member usage "inherits" the feature from the parent usage.

Didn't know quite where to put this so filed against examples.

There are no examples of nested view usages, either within view usages or view definitions. As such it is not clear how view usage hierarchies work – in particular, how do nested view usages in view definitions establish their set of exposed elements.

I can't see anything in the syntax pages that shed any light on this either, and without more guidance I don't understand how to build view usage hierarchies.

Expose relationship is used to map a view usage element to a model element. In case of elements such as featureTyping, Subsetting and others, since they are not namespaces and not memberships, it is not possible to use it for views of such elements.
That creates a problem for consistency using expose for graphical view representations, and requires a "workaround" to capture the relationship between view usages and such elements.

The calculation usage SampledFunctions::interpolateLinear should be a calculation definition. Calculation definitions can be directly called in an expression. There is no need to define a usage.

The generated ISQSpaceTime.sysml library has mistakes in the attribute definition declarations for:

• CylindricalPosition3dVector,
• SphericalPosition3dVector,
• PlanetaryPosition3dVector,
• CylindricalDisplacement3dVector,
• SphericalDisplacement3dVector.

In all declarations the use of AngularMeasureUnit in angular measure quantity attribute usages is wrong and should be replaced by AngularMeasureValue, 8 times.

The constraints validateAttributeDefinitionFeatures and validateAttributeUsageFeatures require that all the features of an attribute definition or usage be referential (non-composite). However, there are a number of models in Domain Libraries that declare attribute definitions or usages with composite features.

1. Analysis Domain Library
   • SampledFunctions
     • Constraint in SampledFunction
   • StateSpaceRepresentation
     • Constraint in StateDeriviative
2. Geometry Domain Library
   • SpatialItems
     • Item SpatialItem::componentNum::elements
3. Metadata Domain Library
   • RiskMetadata
     • Constraint in Level
4. Quantities and Units Domain Library
   • MeasurementReferences
     • Constraint CoordinateTransformation::validSourceTargetDimensions
     • Constraints in CoordinateFramePlacement
     • Constraint AffineTransformationMatrix::validateSourceDimensions
     • Constraint MeasurementUnit::hasValidUnitPowerFactors
   • Quantities
     • Constraints TensorQuantityValue::orderSum and TensorQuantityValu::boundMatch
   • Time
     • Calculation Iso8601DateTime::getElapsedUtcTime
     • Calculation Iso8601DateTimeStructure::getElapsedUtcTime

In the Systems Library model Actions, the action definition AssignmentAction has two parameters, target and replacementValues, in that order. The action usage assignmentActions, which is defined by AssignmentAction, redefines the target parameter, but inherits replacementValues.

The action usage Action::assignments is also defined by AssignmentAction and it subsets assignmentActions. This means that it has two parameters from AssignmentAction and two parameters from assignmentActions as potentially inheritable members. However, assignmentActions::target redefines AssignmentAction::target so the latter is not inherited. And assignmentActions::replacementValues is the same as AssignmentAction::replacementValues, so the former is not inherited again.

The result of this is that the inherited parameters of Action::assignments are AssignmentAction::replacementValues and assignmentActions::target in that order. That is, the parameters of assignments have effectively switched their order relative to how they are defined in AssignmentActions. This is a problem, because an AssignmentActionUsage has an implied specialization of assignments, and it is parsed assuming the parameters inherited from assignments are in the same order as in AssignmentAction.

The production for 'variant-elementusages-compartment' in addition to 'variants-compartment' is an error and should be eliminated from the spec.

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.

The namingFeature of a RenderingUsage that is a viewRendering (i.e., owned via a ViewRenderingMembership) should be the referencedRendering of the owning ViewRenderingMembership.

In 8.3.3.1.10 Type, the OCL for deriveTypeFeatureMembership is

featureMembership = ownedFeatureMembership->union(
    inheritedMembership->selectByKind(FeatureMembership))

with the intent clearly being not to include imported features. The problem is that the inheritedMembership does include imported FeatureMemberships from supertypes. Since Type::feature is derived from featureMembership, this means that a Type may get features that are not owned Features of any of its supertypes and so may have an actual owningType that is not compatible with the original Type.

The extend relationship between use cases is not covered by the transformation.

Currently ConjugatedPortDefinition has a redefinition for effectiveName operation; effective name of conjugated port definition is computed a by prepending the '~' character to the effectiveName of parent port definition.
The analogous arrangement should be done (but is currently missing) for the short names as well.
I.e. The effectiveShortName operation should be redefined for conjugated port definitions (chapter 8.3.12.2); something along the lines:

effectiveShortName() : String [0..1] {redefines effectiveShortName}
 
If the shortName of the originalPortDefinition is non-empty, then return that with the character ~ prepended.
 
body: let originalShortName : String = originalPortDefinition.shortName in
if originalShortName = null then null
else '~' + originalShortName
endif

Correspondingly, the diagram in Figure 17 shall be updated - showing effectiveShortName() redefined;
and the sentence in the 8.3.12.2 chapter header shall be updated, e.g. like this:

Every PortDefinition (that is not itself a ConjugatedPortDefinition) has
exactly one corresponding ConjugatedPortDefinition, whose effective name is the name of the
originalPortDefinition, with the character ~ prepended. Ditto for the effective short name.

In addition to messages, the sequence view should also support streaming flow relationships. Messages only specify abstract communication between entities and, for example, cannot be instantiated in simulations. Streaming flows specify concrete communication between entities, which can also be visualized very effectively in a sequence views.

Currently, sequence views only support messages and successions:
sq-graphical-relationship = message | sq-succession

At the top of the table on page 132 is a line from a requirement to a require constraint with an aggregation indicator at the requirement end. This also appears at the bottom of the table on page 131.
At the bottom of the table on page 132 is a line from a part to a requirement with an arrowhead at the requirement end.
Only the 2nd line is defined within the Graphical Notation section.
Do these both, as it appears, represent the same underlying element? If so how is the tool creator to decide which presentation to use?

The PayloadFeatureSpecializationPart rule in the grammar uses a -> arrow operator that is never explained in Section 8.2.2.1.1 ("EBNF Conventions") tables 27 and 28. Here is how the rule is written:

PayloadFeatureSpecializationPart : Feature =
      ( -> FeatureSpecialization )+ MultiplicityPart?
      FeatureSpecialization*
    | MultiplicityPart FeatureSpecialization+

What does this mean? Should it be simply removed, or?

Currently GBNF only allows specific graphical compartments for specific nodes. For example, a part can only have an interconnection compartment.
An action allows only an action-flow compartment.
There shall be no constraint on the kinds of graphical compartments allowed in a node, and also the number of graphical compartments

In 8.2.2.21.1 Requirement Definitions, the production FramedConcernUsage references CalculationUsageDeclaration. However, there is no CalculationUsageDeclaration defined in the grammar.

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

Currently, distinguished parameters like subject, actor, stakeholder, do not stand out in the graphical notation for symbols that use them.

Consider allowing distinguished parameters in the name compartment of elements that use them, such as RequirementDefinition, RequirementUsage, UseCaseDefinition, UseCaseUsage, etc.

Currently, the compartment names for While Loop, For Loop and If-Else actions differ slightly from their corresponding action names:
• Loop Body is used for the body action in While and For loop actions.
• Then Body is used for the thenClause action in If-Else actions.
• Else Body is used for the elseClause action in If-Else actions.
We understand that these names are intended to enhance user-friendliness. However, since body, thenClause, and elseClause actions can also be visible in the feature chain, aligning the compartment names with their exact action names could improve clarity and maintain consistency across the model.

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'

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

Resolution SYSML2_-400 to FTF2 issue SYSML2_-159 called for updates to the constraints validateAcceptActionUsageParameters and validateSendActionParameters. However, these updates were not made in the final SysML 2.0 specification (see 8.3.17.2 AcceptActionUsage and 8.3.17.15 SendActionUsage).

In subclause 7.17.11 there is an example of a conditional action with the wrong syntax.

if threat.level == high then {
    perform soundAlarm {in cause = threat;}
} else if threat.level == medium then {
    action sendNotification {in msg = threat;}

The "then" is invalid here, it is not a conditional succession.

In the SysML 2.0 specification document, the page numbers for section 1 and 2 use Roman numerals instead of numbers.

PDF page 33 should likely be page '1' instead of 'i'
PDF page 34 should likely be page '2' instead of 'ii'
PDF page 35 where it starts section "2 Conformance" already lists the page number as '3'

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

replace the word crossing with crosses