The declaration of attribute def Iso860DateTimeEncoding in the Quantities and Units Domain Library model Time.sysml still has a TODO comment (line 199):

 * TODO: Add constraint to verify ISO 8691 extended string encoding.

The feature below is intended to identity the same value on all instances, but each instance can identify its own (see KERML-56).

ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame [1] { ... }

Sub-clause 8.2.3.3 (dependencies) uses element-node as the source and target of a dependency.
element-node is not defined anywhere

Subclause 8.2.3.13, specifies the productions for connections. Ballot 3 added a production for n-ary connection usage, but n-ary connection definition (graphical) is still missing

The section describing the mapping class TestCaseVerifyObjectiveMembership_Mapping is incomplete. The subsections Description, General Mappings, Mapping Source, Mapping Target, and Owned Mappings are missing.

In 7.16.1 Actions Overview, in the "Bindings and Flows Between Actions" section, it states in the last paragraph (italics added):

A send action usage includes an expression that is evaluated to provide the values to be transferred, and it specifies the destination to which those values are to be sent (possibly delegated through a port and across one or more interfaces – see also 7.12 and 7.14 on interfaces between ports).

However, the semantics of "delagation across an interface", per the italicized part above, are not described in 7.12 or 7.14, nor are they specified in 8.4.10 Interfaces Semantics.

In 7.17.3 Transition Usages, in the fourth text paragraph, it states:

Transition usages from the entry action are not allowed to have accepters.

There is no validation constraint for this in the abstract syntax.

Is this constraint necessary? If so, a validation constraint should be added. If not, the statement in 7.17.3 should be removed.

proxy refers to proxy-label should be sq-proxy-label
The BNF attempted to reuse the proxy graphics and productions across all three contexts where a proxy may appear (lifeline, ports, and parameters), but all these need to be replaced by proxy graphics specific to each context, including connector line segments above and below, or left and right, in each specific graphic context where a proxy dot may appear.

Clause 8.3.9.5 (OccurrenceUsage), Constraints, says

checkOccurrenceUsageTypeFeaturing
If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.

portionKind <> null implies
  occurrenceDefinition->forAll(occ |
    featuringType->exists(specializes(occ)))

For example, adapted from 7.13.5 (Successions as Usages):

occurrence def Flight {
  timeslice preflight : Preflight [1];
  then timeslice inflight : Inflight [1];
  then timeslice postflight : Postflight[1];

checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:

• all features defined in Pre/In/Postflight "inheriting" to Flight, eg, PreFlight::refuel, would inherit to Flight, with a separate value potentially unconstrained in time from the one happening in preflight.

• valid traces where all the pre/in/postflight values are instances of Flight, which are all required to have pre/in/postflight timeslices.

which probably aren't intended in this exampie.

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.

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.

Documentation should be added that bolding of keywords in the graphical notation is optional, and may be used for visual prominence. For example, in representative notation table 16 in subclause 7.17.1 in the actions compartment of a state the keywords entry, do and exit are bolded.

Notation table shows item flows on interface connections. This is not enabled by the graphical BNF

The way SysML libraries are provided relies on textual notation files on which element declarations do not include the specification of their elementId property.

As consequence, if the elementId is actually generated by the tool, as written in the KerML specification (p226), it is very likely to have a different value from one computer to another and even from one loading to another on the same computer.

Hence, it is impossible to make sure it will "not change during the lifetime of the Element", as required by in the same paragraph of that specification.

Linked to a similar issue raised on KerML

The US Customary Units as specified in NIST SP811 Annex B include a number of units for which the corresponding quantity is not defined in ISO/IEC 80000, the International System of Quantities (ISQ). These units are currently commented out in Quantities and Units Domain Library USCustomaryUnits. Examples are:

//attribute <'Btu_IT/ft³'> 'British thermal unit (IT) per cubic foot' : EnergyDensityUnit = Btu_IT/ft^3;
//attribute <'gal/(hp⋅h)'> 'gallon (US) per horsepower hour' : EnergySpecificVolumeUnit = gal/(hp*h);
//attribute <'mi/gal'> 'mile per gallon (US)' : FuelEconomyUnit = mi/gal;
//attribute <'lb/(hp⋅h)'> 'pound per horsepower hour' : FuelConsumptionUnit = lb/(hp*h);

An additional extension package for ISQ is needed that declares the attribute definitions for the missing quantity and measurement unit types, e.g.:

• EnergyDensityValue and EnergyDensityUnit
• EnergySpecificVolumeValue and EnergySpecificVolumeUnit
• FuelEconomyValue and FuelEconomyUnit
• FuelConsumptionValue and FuelConsumptionUnit

It should be considered whether or not to include the new library package inside ISQ, as formally these quantity and unit types are not part of ISO/IEC 800000.

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.

The line-arrows in the current graphical notation for ports with directional features are badly readable in large, busy diagrams.

The same solid triangular arrow symbols as for parameters should be used on ports with directional features.

The current graphical notation for parameters is similar to SysML v1, i.e. a (rounded) square attached to outside of the border of an action symbol. A directional parameter has a line arrow indicating in, out or inout direction. The notation is inconsistently depicted: both full squares outside the border and half squares outside the border (like in SysML v1) are used. See e.g., Representative Notation Table in section 7.16.1 page 194.

There should be a single standard notation that is clearly differentiated from port symbols. Also, the direction arrows should be clearly readable in large and busy diagrams with many parameters (nested and non-nested).

Alternative parameter symbol notation has been developed that uses a circular shape that straddles the border of the owning action (definition or usage), and has solid triangular arrow symbols.

No productions for case view. All case-related productions were included in general view, since no specific subset was finalized during discussions. Consider defining as a subset view, like other general view subsets. Incorrect reference to 9.2.19.1.

The textual notation should be regularized between the until loop and while loop.

The proposed update is loop while action actionName where action and actionName are optional.

The graphical notation for allocating a flow to a connection, that is consistent with textual notation, is missing.

This should be added.

The mapping of a UML4SysML::InterruptibleActivityRegion is not covered by the transformation rules.

The transformation generally maps a PseudoState, but does not distinguish between the different kinds of pseudostates.

The transformation does not specify mapping rules for UML4SysML::ActivityPartition.

The details of the mapping of UML4SysML::DataStoreNode and UML4SysML::CentralBufferNode are not specified.

The transformation does not specify mapping rules for UML4SysML::SignalEvent.

The transformation does not specify mapping rules for SysMLv1::FlowProperty.

In 7.12.1 Ports Overview, at the end of the third paragraph, it states

A transfer can occur from the out features of one port usage to the matching in features of connected port usages. Transfers can occur in both directions between matching inout features.

It is unclear whether this is intended to mean that such transfers happen automatically in some way, or if it just means that it is possible to have such transfers by adding explicit flows to the model. If the former is intended, then this does not seem to be currently supported by port semantics (8.4.8). If the latter is intended, this should be made more clear.

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.

In subclause 7.13.1, Table 15, in example "Flows Compartment" the graphical notation is missing. Graphical notation corresponding to the example expressed in textual notation should be added. Also, the corresponding graphical BNF production for flows-compartment is missing in subclause 8.2.3.13, so that should be added too.

Currently sq-ev-occurrence is denoted as an "X", which is not used anywhere else. Should it be rather the proxy notation, i.e., a black dot?

A variant is an owned member of its variation and is also a specialization of its variation. As a result, the variant inherits the owned member relationships from its variation.

This appears in the diagram in the attached example (file name: variant_inheritance_from_variation_issue_sf_2023-04-12). The transmissionAutomatic has an inherited ownedMembership to the transmissionManual and to itself. This applies to the transmissionManual as well.

Refer to the spec clauses as 8.2.3.5 Namespaces and Packages Graphical Notation and 8.2.3.6 for Definition and Usage Graphical Notation (where variation is introduced).

The mapping of a UML4SysML::ActivityFinalNode is not covered by the transformation rules.

The current algorithm crashes if the data type provided has no name defined or if the type is not defined

Comment_Mapping is missing a default rule locale

The graphical BNF for binary ConnectionDefinition does not clearly indicate the source and target ends.
The graphical BNF should provide the optional ability to include source and target notation, with arrow head or source and target keywords.

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.

BNF production is missing for n-ary connection def and connection usage as in examples shown in the representative notation table in 7.13.1 Connections Overview. Must be fixed in 8.2.3.13.

Check all examples of n-ary connections (including causation and requirements derivation) to replace arrowheads with bolded end names. Connections of 3 or more ends only have target ends, no source ends, see KerML spec clause 7.4.5.

A mapping of the Graphical BNF productions to the abstract syntax has not been addressed.

If no specific proposal is considered by the FTF, it may be worth including some discussion notes in the spec in place of any detailed mapping.

There should be explicit specification and explanation, that a diagram and a compartment are views, as well as clarification on how the filter notation can be applied to a view compartment and to a diagram. Consider an extension to the filter notation.

Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.

Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders

Graphical BNF specifies a flow connection. It is not clearly mapped to a semantic language concept. Should it be merged with a message specified as part of occurences?

The graphical representation of metadata definition and semantic metadata definition is missing from the specification. The resolution should include the addition of one or more entries in the representative notation tables of metadata definition, for both regular and semantic metadata definition, and the graphical BNF should be updated to support this capability.

See also the explanation in https://github.com/Systems-Modeling/SysML-v2-Pilot-Implementation/releases/tag/2022-09 .

Right now use-case nodes cannot be associated with actors and subjects. They need to be made subject/actor stakeholders

The graphical notation lacks clear differentiation between the various types of flows in the language: flow, succession flows, and message flow (see also SYSML2-59).
In addition, the BNF was overly restrictive and did not allow flow connections on structural diagrams, except for flows on connections.
Flows on connections also need to include messages and succession flows.
It needs to be corrected in the BNF in the relevant clauses
8.2.3.9 - Occurrences (SD notation)
8.2.3.13 - Connections
8.2.3.14 - Interfaces
8.2.3.16 - Actions

Keywords introduced in the graphical notation BNF are surrounded by guillemets («...»). However, the graphical notation also uses snippets of textual notation in many places, often by referencing productions from the textual notation BNF, which does not put guillemets around keywords. In some cases, though, the graphical BNF will include productions for text that introduce keywords that parallel the textual notation, but don't directly use textual notation BNF productions. The resolution to SYSML2-59 includes such productions for message-label and flow-label that include the «of» keyword surrounded by guillemets, but other such productions in the graphical BNF do not put guillemets around keywords. There needs to be a consistent rule on how guillemets are to be used in the graphical notation.

Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match

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

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

Both Enumeration and ValueType have main mappings and their specified filters do prevent a double match

The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27

In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.

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

The current algorithm crashes if the data type provided has no name defined or if the type is not defined

The current specification is not computable in some cases (where the "any" OCL iterator find no value). E.g. : MIWG Test Case#27

In some cases (e.g. MIWG test case #11) it is unable to compute the requested type.

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

The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping

Factories for LiteralInteger, LiteralInfinity are required

ownedRelationship() operation. There is the following code:

   else if from.oclIsTypeOf(UML::FlowFinalNode) then
       ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName =  'Actions::Action::done')))

The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing

Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance

ownedRelationship() operation. There is the following code:

   else if from.oclIsTypeOf(UML::FlowFinalNode) then
       ObjectFlowItemFlowEndRedefinition_Factory.create(ElementMain_Mapping.getMapped(SysMLv2::ActionUsage.allInstances()->any(e | e.qualifiedName =  'Actions::Action::done')))

The point is that the parameter of a getMapped operation shall be an element form the source model, while the code above povide a SysMLv2 element from a library. This makes the MIWIG test case #27 failing

The multiplicities that the transformation specifies are wrong when the source element has the default multiplicity in the source model.
Shall be fixed: MultiplicityUpperBoundOwningMembership_Mapping and MultiplicityLowerBoundOwningMembership_Mapping
Shall be removed : DefaultLowerBound_Mapping and DefaultUpperBound_Mapping

Factories for LiteralInteger, LiteralInfinity are required

Duplicated operations can be removed by adding a common abstract root class. This will simplify the model and ease the maintenance

The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35

The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it

Clause 8.3.9.5 (OccurrenceUsage), Constraints, says

checkOccurrenceUsageTypeFeaturing
If the portionKind of an OccurrenceUsage is not empty, then, for each occurrenceDefinition of the OccurrenceUsage, there must be a featuringType of the OccurrenceUsage which either is the occurrenceDefinition or directly or indirectly specializes it.

portionKind <> null implies
  occurrenceDefinition->forAll(occ |
    featuringType->exists(specializes(occ)))

For example, adapted from 7.13.5 (Successions as Usages):

occurrence def Flight {
  timeslice preflight : Preflight [1];
  then timeslice inflight : Inflight [1];
  then timeslice postflight : Postflight[1];

checkOccurrenceUsageTypeFeaturing requires Flight to specialize each of Pre/In/Postflight, even though these would typically be disjoint with Flight, leading to:

• all features defined in Pre/In/Postflight "inheriting" to Flight, eg, PreFlight::refuel, would inherit to Flight, with a separate value potentially unconstrained in time from the one happening in preflight.

• valid traces where all the pre/in/postflight values are instances of Flight, which are all required to have pre/in/postflight timeslices.

which probably aren't intended in this exampe.

The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.

This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages

The MIWIG test case #11 fails because it assumes that the client of a SysML::Satisfy relationship, that is a Block, is owned by something that is mapped to a SysMLv2 Type.

This is unlikely to happen since in most cases (like in this test case) Blocks are owned by Packages

The MWIG test case #8 fails because it contains a property that is typed by an Actor while the transformatiosn currently defined do not support it

The filter operations defined for the mapping specified from an OpaqueBehavior prevent those owned by another kind of element to be transformed, like in MWIG test cases 7 and 35

GenericToStateUsage_Mapping is missing a default rule for isParallel

GenericToElement_Mapping is missing default rules for:

• owningRelationship
• aliasIds
• declaredShortName
• isImpliedIncluded

A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property

Comment_Mapping is missing a default rule locale

The body condition specified for this operation is wrong. It should be an empty set.

GenericToElement_Mapping is missing default rules for:

• owningRelationship
• aliasIds
• declaredShortName
• isImpliedIncluded

The body condition specified for this operation is wrong. It should be an empty set.

GenericToStateUsage_Mapping is missing a default rule for isParallel

A Namespace shall own the relationships that defined its members (either owned or not) and its import relationships.
Instead the ownedImport() operation is useless since Namespace::ownedImport is a derived property

GenericToRelationship_Mapping should provide default rules for

• owningRelatedElement
• isImplied

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

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.

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.

GenericToRequirementUsage_Mapping is missing a default rule for reqId