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

if threat.level == high then {
perform soundAlarm

} else if threat.level == medium then {
action sendNotification

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

It is possible to define flow usage in several ways.

One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

   flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the payload

   flow {
      :>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
      end ::> firstEndCon;
      end ::> secondEndCon;
   }

Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).

Now the problem is that two different models are created for these two cases. PayloadFeature is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case.

It seems that PayloadFeature (meta)type is mostly a syntactic marker. So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint?

This non-uniformity causes several technical problems down the line.

• It does not allow to have other kind of features (for example ReferenceUsage in SysML) as item features on Flows. ReferenceUsage is not inherited from PayloadFeature
• PayloadFlow::payloadFeature derived property returns only owned flow payload feature, but in practice actual (owned or inherited) one should be returned.

The second problem could perhaps be solved by e.g. changing the definition of the payloadFeature property in the abstract syntax to be the feature that specializes `Transfer::payload`, whether or not it is owned or inherited, and whether or not it is a PayloadFeature. The derivation would not be as simple as the current one, but it would be a reasonable suggestion.

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'

Currently graphical notation does not seem to support compartments for extentions based of keywords. For example, if there is a new semantic meta data <<cpu>>, there is no way to create a compartment for CPUs. OTOH, it is possible to create a node with a <<cpu>> keyword.

The use and meaning of "import all" are documented in the combination of the BNF and abstract syntax but is not described at all in Clause 7 of either the KerML or SysML v2 specs. It should be mentioned there, ideally with an example.

Are there any other similar features that are documented in the BNF and abstract syntax but not described in Clause 7?

There are inconsistencies in the SysML v2 representative notation tables related to the notation of “ref part”. In particular, several tables—such as Table 4 (Section 7.6.1, p. 38) and Table 11 (Section 7.13.1, pp. 67–68)—do not match the rules defined in the Generalized BNF (GBNF).
According to Section 8.2.3.11 of the GBNF, the part(-def)-name-compartment requires a prefix (e.g., OccurrenceUsagePrefix or DefinitionPrefix) to indicate the element’s role. When the element is referential, the prefix “ref” must be explicitly included.
The omission of the “ref” prefix in these tables does not comply with the GBNF rule, and should be regarded as incorrect. To maintain alignment with the GBNF and ensure clarity in the notation of referential parts, the missing “ref”prefix should be added in the affected tables.

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.

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.

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.

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.

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.

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

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.

Compartment in Table 13 says "allocated"...

allocations-compartment has the marker called "allocations"

I think one of these need to be changed

Cases can be used "in its own right"... there needs to be a graphical notation for Cases

confirm state-actions-compartment is "states" not "state actions"

in the graphical notation for states the compartment name is "exhibit states" ... yet in the example in table 17 there is exhibits and exhibitedBy

is this a mistake?

action-def-name-compartment =
'«' DefinitionPrefix 'action' 'def' '»'
definition-name-with-alias<

don't think the ending < should be there

Currently flow connections can be connected to control nodes such as decision/merge/fork/join using parameters, and the behavior needs to be explicitly specified like in any action. This is a limitation comparing to UML that allowed flows to be seamlessly connected to control nodes with proper semantics to cover such connections. In SysML V2 the current approach is to specify parameters on control nodes to handle this. There are two main issues here:

• Weaker expressive power comparing to UML/V1
• Challenging to support graphically with "opaque" symbols like fork or decision

The expectation is to provide proper semantics to connect flow connections similar to UML/V1, and keep the graphical symbols "atomic" without having to add compartments or parameters, at least for "default" use cases

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.

Currently name compartment keywords are pulled via DefinitionPrefix, which does not include 'variant'. Textual syntax introduces variant via a special VariantUsageMember production.
GBNF needs to explicitly add ability to use 'variant' keyword for all usage nodes

There are two productions for calc-name-compartment, not labeled as partial.

Also, there is no specific production for the result of a calculation other than in a compartment. Should the result parameter of a calculation be graphically depicted in the same manner as an out parameter on an action would?

Recommend adding an example to Table 18 to clarify the expected notation for in and result parameters.

The production for usage-node appears to have a typo: "occurrence-refxfx" should probably be "occurrence-ref"

The following library models include the declaration of types that have inherited members with the same name, because of diamond inheritance of redefined features.

Systems Library

• Actions
• Flows
• Interfaces
• Items
• Metadata
• Ports
• SysML
• VerificationCases
• Views

Analysis Domain Library

• AnalysisTooling

Cause and Effect Domain Library

• CauseAndEffect

Geometry Domain Library

• ShapeItems

Metadata Domain Library

• ImageMetadata
• ModelingMetadata
• ParametersOfInterestMetadata
• RiskMetadata

Quantities and Units Domain Library

• SI
• USCustomaryUnits

Requirement Derivation Domain Library

• RequirementDerivation

The analysis case definition TradeStudy from the Analysis Domain Library model TradeStudies.sysml is intended to be used by redefining the objective tradeStudyObjective to use a concrete specialization of TradeStudyObjective, e.g., MinimizeObjective or MaximizeObjective. For example:

analysis tradeStudy : TradeStudy {
    objective minimize :>> tradeStudyObjective : MinimizeObjective;
    ...
}

However, MinimizeObjective and MaximizeObjective redefine the parameters from TradeStudyObjective, and TradeStudy::tradeStudyObjective also redefines the first three of these parameters (selectedAlternative, alternatives and eval). But this means that both sets of redefinitions are inherited by the objective minimize in the analysis case usage above, which is semantically inconsistent. Currently, the only way to avoid this is for the modeler to include nested redefinitions of selectedAlternative, alternatives and eval when redefining tradeStudyObjective, which is inconvenient and unintended.

Due to the problem identified in KERML11-72, a state usage that is a substate may end up inheriting two different redefinitions of Occurrence::Occurrence::this, but both with the name this, resulting in a violation of the constraint validateNamespaceDistinguishibility.

1. The library usage Actions::Action::subactions specializes all of Actions::Action, Actions::actions and Performance::Performance::subperformances.
2. subactions has a nested redefinition of this, which is resolved as a reference to Occurrences::Occurrence::this that is inheritable from Action.
3. subperformances also redefines Occurrences::Occurrence::this and the redefined feature Performances::Performance::subperformances::this is also inheritable by subactions. However, it is not actually inherited because it is overridden by the direct redefinition of Occurrences::Occurrence::this in subactions.
4. The library usage States::StateAction::subactions redefines Actions::Action::subactions. It does not have a nested redefinition of this.
5. Among other things, StateAction::subactions also has an implied specialization of subperformances. However, since subaction is already a subtype of subperformances, this implied specialization can be considered redundant and not included. But, according to KerML specification subclause 8.4.2 (Semantic Constraints and Implied Relationships), a tool is not required to exclude such an implied specialization, so the specialization of subperformances could be included.
6. If the implied specialization of subperformances is included, then subperformances::this will be inherited by StateAction::subactions in addition to Action::subactions::this.
7. The usage StateAction::substates specializes StateAction::subactions, and every state usage that is a substate is required to specialize StateActions::substates. As a result, if StateAction::subactions gets two this features, these will be inherited by every substate.

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

The constraint checkRequirementUsageSubrequirementSpecialization requires that a composite RequirementUsage whose ownedType 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.

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::getElapsedTime
     • Calculation Iso8601DateTimeStructure::getElapsedUticTime

There is no textual syntax to use fork, join, merge, and decision in statemachines textual syntax.
It is supported by the graphical notation which is also a misalignment issue

In commercial practice, many variation points are optional meaning that its variants are present or not. A SysML v2 variation currently only allows its members to be its variants which are always identified with multiplicity 0 or 1 for an optional variation.  It is desired that a variation that is optional receive special treatment to facilitate its use by PLE methods and tools.  In particular, it is desired to provide a unique way to identify an optional variation and to enable it to include its features instead of its variant members.

The transformation does not consider the mapping of a property typed by an Actor. It should be mapped to a usage defined by the target element of the Actor.

There is no rule that maps a property typed by a Signal. It should be mapped to an item usage.

All feature redefinitions specified in the transformation model, whether they affect properties or operations, should appear in the specification document

The SysML v1 stereotype Stakeholder is applied to Classifiers. Therefore, it could also be other model elements than Class which represent stakeholders. The usage of Actor is quite common.

Actors are mapped to PartDefinition. Therefore, Stakeholders should also be mapped to PartDefinition which makes it more consistent. Stakeholders and Actors are different concepts, but there seems to be no reason to map them differently to parts and items.

ConnectorProperty is deprecated but still part of SysML v1.7. So, the transformation should provide a mapping for it.

The mapping of a ProfileApplication is not covered by the transformation.

Unfortunately, a small error has crept into the resolution of SYSML2_-203.

The mapping class InitialStateMembership_Mapping should be named InitialStateSubactionMembership_Mapping and the general mapping of the mapping class should be GenericToSubactionMembership_Mapping.

Accordingly, change InitialStateMembership_Mapping in Helper::stateOwnedRelationship() to InitialStateSubactionMembership_Mapping.

The pins of a CallBehaviorAction are not mapped. Although the parameters of the action usage are inherited from the action definition, the pins must be mapped since they can have different names than the behavior parameters, different types, etc.

Currently, ActivityParameterNodes are not mapped to v2. Instead, only the Parameter of the Activity is mapped to a parameter of the ActionDefinition. However, it is not possible to connect the parameter by a succession flow with a parameter of an action usage, for example.

Instead, map an ActivityParameterNode to an ActionUsage with corresponding input and output parameters and bind the ActionDefinition parameter with the corresponding ActionUsage parameter. For example:

action def {
  in inputParameter: Integer;
  bind inputParameter = __inputParameter.outbound;
  action __inputParameter {
    in ref outbound;
    out ref inbound: Integer;
  }
}

The mapping creates a calc inside a constraint definition. The result parameter of the calc should be bound to the result parameter of the constraint.

The transformation maps a constraint to a constraint definition and a constraint usage. The ConstraintDefinition should be defined as ConstraintUsage and the previously generated ConstraintUsage can be removed.

As mentioned in section "7.7.2.3.7.20 ClearStructuralFeatureAction_Mapping": The details of the mapping are not defined yet.

As mentioned in section "7.7.2.3.7.34 RemoveStructuralFeatureValueAction_Mapping": The details of
the mapping are not defined yet.

The mapping AddStructuralFeatureValueAction ignores the names of the input and output pins and uses the names defined in the SysMLv1Library::AddStructuralFeatureValueAction element.

checkRenderingUsageSpecialization requires that a RenderingUsage specialize the base
RenderingUsage Views::rendering (see 9.2.19.2.7 ).

need Views::renderings (with an "s")

The constraint checkIncludeUseCaseSpecialization should be named checkIncludeUseCaseUsageSpecialization.

In current implementation each FlowUsage owned by PartUsage subsets (automatically) 3 features:

1. FlowUsage::flows
2. PartUsage::subparts
3. ActionUsage::ownedActions

This could be optimized for the sake of model size. Maybe it would be better idea to introduce

    Part::Part::ownedFlows :> ownedActions, subparts, flows

and define something like CheckFlowConnectionSubFlowSpecialization constraint?

The textual notation production AnnotatingMember in 8.2.2.4.1 Annotations is used in the special syntax for EnumerationBody to allow the bodies of EnumerationDefinitions included AnnotatingElements as members. However, AnnotatingMember does not include the MemberPrefix that allows for visibility to be specified for a normal DefinitionMember. This means that AnnotatingElements in EnumerationBodies cannot currently have any visibility other than public, even though there is no such restriction in the abstract syntax.

When discussing verdicts "The result of the validation case is a verdict..." should this be "The result of the verification case is a verdict..."?

The semantic constraint checkRequirementUsageObjectiveRedefinition requires that

A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage.

But this doesn't handle the case in which the owningType may be specialized by a feature chain whose featureTarget is a CaseUsage.

The OCL for the constraint checkDecisionNodeOutgoingSuccessionSpecialization references the library element ControlPerformances::MergePerformance::outgoingHBLink, but the correct qualified name is ControlPerformances::DecisionPerformance::outgoingHBLink

The constraint checkActionUsageSubactionSpecialization checks that the operation isSubactionUsage is true before requiring that an ActionUsage specialize Actions::Action::subactions. The operation isSubactionUsage not only checks the ActionUsage is composite and has an owningType that is an ActionDefinition or ActionUsage, but also ensures that the ActionUsage is not an entry or exit action. Various subclasses of ActionUsage have semantic constraints that require more specific specializations of subactions but do not include the condition that the usage is not an entry or exit action:

• checkCalculationUsageSubcalculationSpecialization
• checkRequirementUsageSubrequirementSpecialization
• checkCaseUsageSubcaseSpecialization
• checkAnalysisCaseUsageSubAnalysisCaseSpecialization
• checkVerificationCaseUsageSubVerificationCaseSpecialization
• checkUseCaseUsageSubUseCaseSpecialization

In SysML section 7.17.9 (BETA 4) - Assignment Action Usages, the code comment in the textual example is inconsistent with the language in the English.

The English says:
"An AssignmentAction sets a referent feature of a target occurrence to a new assigned value."

But the code comment says:

action def UpdateVehiclePosition {
    in part sim : Simulation;
    in attribute deltaT : TimeDurationValue;
    // The target of the assignment below is "sim".
    // The referent feature chain is "vehicle.position".
    assign sim.vehicle.position :=
        sim.vehicle.position + sim.vehicle.velocity * deltaT;
    // After the above assignment "sim.vehicle.position" has the
    // value of the result of the assigned value expression,
    // evaluated at the time of the assignment.
}

The comment should probably identify "position" as the referent (not "vehicle.position" ! ) and "sim.vehicle" as the target, since "vehicle" features "position" ("sim" does NOT feature "position" and therefore "sim" cannot be the target).

Consistent with the 'var' feature being featured by "vehicle" and not "sim", I would expect "sim.vehicle" to declare the occurrence for the purposes of the assignment. Otherwise, using "sim" as the occurrence would require more complex semantics involving the 'var' behavior of an intermediate occurrence as part of the assignment action, which is unnecessary.

In the description and OCL for the constraint checkViewpointDefinitionSpecialization, Views::Viewpoint should be replaced with Views::ViewpointCheck. In the description and OCL for the constraint checkViewpointUsageSpecialization, Views::viewpoints should be replaced with Views::viewpointChecks.

The description in clause 9.8.8.2.4 is missing the three words at the end of the sentence.
'its start snapshot.'
The above description in the SysML specification should align with corresponding clause 9.2.12.2.5 in the KerML specification to read as follows:
DurationOf returns the duration of a given Occurrence relative to a given Clock, which is equal to the TimeOf the end snapshot of the Occurrence minus the TimeOf its start snapshot.

It is possible to define flow connection usage in several ways.

One - use the simple/nice notation where syntactic sugar hides the underlying complexity:

flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the flow ends:

flow of SomeItemDefinition {
    end ::> firstEndCon {
       //more end characteristics can be specified here:
       :>>sourceOutput, someFlowPropertyofEnd1;
    }
    end ::> secondEndCon {
       :>>targetInput, someFlowPropertyofEnd2;
    }
}

Sometimes the second, detailed way is the only way to define characteristics of the ends in the more complex cases. Now the problem is that two different models are created for these two cases. ItemFlowEnd is created for the first/nice/short case while simple ReferenceUsage is created for the full/complete case

It seems that ItemFlowEnd (meta)type is mostly a syntactic marker.So perhaps it would be possible to get rid of it entirely and make the two cases equivalent from the abstract syntax/model standpoint (by using just ReferenceUsage)?

For example, here "A view definition includes filter conditions on what kinds of elements can be included in a view". can this be interpreted as view usage?

The term view is used a lot and I'm wondering whether it always means "view usage".

The spec says "A view definition includes filter conditions on what kinds of elements can be included in a view" here but elsewhere in 7.25.1 says "view conditions". are these the same?

For some reason, the textual syntax for interface usage limits the set of elements allowed in its body (see InterfaceBody in clause 8.2.2.14.1). This prevents users from redefining inherited attributes in the usage:

interface myInterface : MyInterfaceDef // MyInterfaceDef defines attribute x
  connect end1 ::> end1InOuterScope
  to end2 ::> end2InOuterScope {
    redefines x = 5; // syntax error
  }

on a EnumerationDefinition we want isVariation=true and readonly (should not be allowed to be changed

Change ItemUsage is a ItemUsage to ItemUsage is an OccurenceUsage

checkItemUsageSubitemSpecialization should have description

An ItemUsage that is composite and has an owningType that is an ItemDefinition or ItemUsage must specialize the System model Library ItemUsage Items::Item::subitems

checkPartUsageStakeholderSpecialization wording should be

If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.

i.e. remove the word "either"

checkPartUsageStakeholderSpecialization wording should be

If a PartUsage is owned via a StakeholderMembership, then it must directly or indirectly specialize Requirements::RequirementCheck::stakeholders.

i.e. remove the word "either"

/conjugatedPortDefinition : ConjugatedPortDefinition [0..1]

The that is conjugate to this PortDefinition.

should be

The ConjugatedPortDefinition that is conjugate to this PortDefinition.

the standard alludes to validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the PortDefinition that are not PortUsages are referential (non-composite).

but no OCL definition of validatePortDefinitionNestedUsagesNotComposite is in the standard

the standard alludes to

validatePortDefinitionNestedUsagesNotComposite requires that all nestedUsages of the PortDefinition that are not PortUsages are referential (non-composite).

but no OCL definition of validatePortDefinitionNestedUsagesNotComposite is in the standard

in interfaces.sysml

end port source: Port :>> BinaryConnection::source;
end port target: Port :>> BinaryConnection::target;

but 9.2.7.2.1 BinaryInterface has

source : Port [0..*]

target : Port

so one of these sources is wrong

Don't think we need

validateObjectiveMembershipIsComposite

it is composite in the metamodel

Actions::SendAction descriptions not the same as in the Library file

Actions::AcceptMessageAction has different descriptions than in the library

Actions::TerminateAction documentation is not coordinated between section 9.2.10.2.24 and the library files

Actions::MergeAction descriptions are different than in the system library file

Actions::DecisionAction descriptions are different are different than in their library files

Actions::DecisionTransitionAction has different descriptions

"has a single guard" in standard vs "has a guard" in standard file

Actions::AcceptAction descriptions differ between Standard and Standard Library

Actions::acceptActions descriptions are different between Standard and Standard Library File

acceptActions is the base feature for all SendActionUsages.

vs

acceptActions is the base feature for standalone AcceptActionUsages

The OCL for thee validateAssignmentActionUsage constraint is

referent <> null implies referent.featureTarget.mayTimeVary

However, referent.featureTarget has the type Feature, not Usage, so mayTimeVary is not defined for it. Instead, isVariable should be used.

The constraint validateAssignmentActionUsageReferent is described as

An AssignmentActionUsage must have an ownedMembership that is not an OwningMembership and whose memberElement is a Feature.

This is intended to support the derivation of AssignmentActionUsage::referent, however, the constraint deriveAssignmentActionUsageReferent is

The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not a FeatureMembership.

Note that the derivation only excludes FeatureMembershps, not all OwningMemberships. Indead, a referent that is a feature chain will be owned by the AssignmentActionUsage using an OwningMembership.

The resolution to SYSML2_-417 was supposed to change all uses of "FlowConnection" in names to "Flow". However some changes were missed.

1. 8.3.6.2 Definition, constraint deriveDfinitionOwnedFlow, in the OCL, FlowConnectionUsage should be FlowUsage.
2. 8.3.6.4 Usage
   • Attribute nestedConnection, in the description, FlowConnectionUsages should be FlowUsages.
   • Constraint deriveUsageNestedFlow
     • In the description, FlowConnectionUsages should be FlowUsages.
     • In the OCL, FlowConnectionUsage should be FlowUsage.
3. 8.3.13.5 ConnectorAsUsage, in the description, FlowConnectionUsage should be FlowUsage.
4. 8.4.12.1 Flow Definitions, first paragraph, last sentence, FlowConnection should be FlowUsage.
5. 8.4.12.3 SuccessionFlowUsages, first paragraph, second to the last sentence, "FlowConnectionDefinition SuccessionFlowConnection" should be "FlowDefinition SuccessionFlow".

In the constraint deriveSatisfyRequirementUsageSatisfyingFeature, in the if condition, the subexpression

bindings->first().relatedElement->exits(r | r <> subjectParameter)

should be

not bindings->first().relatedElement->exists(r | r <> subjectParameter)

The constraint checkSatisfyRequirementUsageBindingConnector requires that "A SatisfyRequirementUsage must have exactly one ownedMember that is a BindingConnector between its subjectParameter and some Feature other than the subjectParameter." However, in the textual notation for a SatisfyRequirementUsage, a *by* is parsed as a FeatureValue binding from the owned subject of the SatisfyRequirementUsage to the *by* clause Expression (see 8.2.2.21.2 Requirement Usages). But the implied BindingConnector for a FeatureValue will then be owned by the subject parameter, not by the SatisfyRequirementUsage, so the checkSatisfyRequirementUsageBindingConnector constraint will be violated.

1. The reserved keywords of SysML are the following.

The following keywords (in the Beta 3 document I have downloaded) I believe are missing: constant, effect, feature, locale, meta, and new.

The resolution to SYSML2_-248 changed the name of the fn parameter of TradeStudies::TradeStudyObjective and its specializations to eval. However, invocations of this parameter in the bodies of MaximizeObjective and MinimizeObjective where not correspondingly updated in the full textual notation in file TradeStudies.sysml.

According to 8.4.16.2 Constraint Usages, "checkConstraintUsageCheckedConstraintSpecialization requires that a composite ConstraintUsage whose owningType is an ItemDefinition or an ItemUsage...specialize the ConstraintUsage Items::Item::checkedConstraints...". However, the definition of checkConstraintUsageCheckedConstraintSpecialization in 8.3.20.4 does not actually test if the ConstraintUsage is composite.

This issue is with v2 Beta 4.

In the following textual notation, vehicle does not have a drives occurrence. Later in the notation, the message sequence references a vehicle.drives feature, which is erroneous.

use case def 'Provide Transportation' {
    subject vehicle : Vehicle {
        event occurrence driverEnters [1];
        then event occurrence passengerEnters [0..*];
        then event occurrence startsDrive [1];
        then event occurrence endsDrive [1];
        then event occurrence passengerExits [0..*];
        then event occurrence driverExits [1];
    }
    actor driver : Person {
        event occurrence entersVehicle [1];
        then event occurrence exitsVehicle [1];
    }
    actor passengers : Person[0..4] {
        event occurrence entersVehicle [1];
        then event occurrence exitsVehicle [1];
    }
    actor environment : Environment {
        event occurrence vehicleDrives [1];
    }
    objective {
        doc
        /* Transport driver and passengers from starting location
         * to ending location.
         */
    }
    message of Enter from driver.entersVehicle to vehicle.driverEnters;
    then message of Enter from passengers.entersVehicle to vehicle.passengerEnters;
    then message of Drive from vehicle.drives to environment.vehicleDrives;
    then message of Exit from passengers.exitsVehicle to vehicle.passengerExits;
    then message of Exit from driver.exitsVehicle to vehicle.driverExits;
}

We need to update the defaults for owned non-abstract Actions to ensure expected interpretations of when and how Actions will start when executing their parent (owning Action, Part, or Occurrence).

Background:

Modelers creating SysML would like good defaults to make modeling Action sequences simple, easy to declare, and easy to interpret. The main discussion stems around potential confusion in the case where some owned Actions have zero incoming successions (but are possibly expected to "start automatically").

In UML, Actions that did not require any incoming control or flow tokens would "start automatically" without requiring a control token. Essentially, they would not be blocked from starting by requiring them to wait for a control token. In SysMLv2, we no longer have control tokens and instead rely on Successions (HappensBefore connectors) to constrain the relative time ordering of behaviors. While it's clear (pending other RTF issues around end multiplicities) that the intent of a succession is to ensure that a target Occurrence occurs for every instance of a source Occurrence, it is less clear what would happen in the absense of any such succession.

Currently, the default multiplicity of Actions in SysML is inherited from KerML as [0..*]. As part of execution, there is some major question around whether there is any indication that such an action would occur at all with a lower bound multiplicity of zero. So, a model where the action does NOT execute is valid!

See attached for reference models. Consider the following textual models:
Explicit (All actions have successions from start)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    first start then a1;
    first start then a2;
    flow from a1.x1 to a2.x1;
}

Implicit (No actions have incoming successions)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    flow from a1.x1 to a2.x1;
}

Mixed (Some actions may have successions from starts but others do not)

action a0{
    action a1{
        out x1;
    }
    action a2{
        in x1;
    }
    first start then a1;
    flow from a1.x1 to a2.x1;
}

The open question is: when and how do actions 'a1' and 'a2' start in the context of 'a0' for these different models?

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

According to the specification, items can own actions and parts can perform actions.

However, the feature "ownedActions" is owned by the library element Part and not Item. The feature "performedActions" is also owned by Part which is correct.

viewpointConformance is not defined in the standard library
should be stubbed out...

abstract view def View :> Part {
...
viewpoint viewpointSatisfactions : ViewpointCheck[0..*] :> viewpointChecks, checkedConstraints
satisfy requirement viewpointConformance by that

}

An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages

I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...

but
exhibitedStates : StateAction [0..*]

ownedStates : StateAction [0..*]

are in Parts (not in Item) ... is this wrong??

An item may have attributes (see 7.7 ), states (see 7.18 ), and nested item usages

I agree items should be able to have states (e.g. Document has states "underReview", "Reviewed")...

but
exhibitedStates : StateAction [0..*]

ownedStates : StateAction [0..*]

are in Parts (not in Item) ... is this wrong??

validateUsageVariationMembership is missing a OCL statement

should sunroof be multiplicity 0..1? for optional?... or is this another way to show optional (but not stated in the standard)..