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

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.

In 7.15.1 Allocations Overview, Table 17, entry for "Allocation (with sub allocation)", the name acton1 in the graphical notation should be action1.

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.

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.

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.

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

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.

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

Some Standard View Definitions, like Case View, are not a self-standing view, but are effectively a General View with a specific filter applied.

Add filtered views as specializations of General View into the first table "Standard View Definitions" of clause 9.2.19.1, in particular Case View, with an explicit filter declaration.

There is no Graphical BNF for grid rendering, required by the Grid View Standard View Definition.

This should be added.

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

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.

Requirement derivation, cause effect, and refinement are missing in the representative notation tables.

Add examples in both graphical and textual notation for requirement derivation, cause effect, and refinement.

Standard geometric view is identified, but contents are not specified yet. An initial description is given in the doc comment in 9.2.19 library element <gev> GeometricView.

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.

Clarify how to show the owning context for a nested feature in a graphical view such as a state transition view (Proposed solution: consider 'exhibited by vehicle' for state transition view of vehicleStates).

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

This should be added.

Identify the implications of views on the model organization and how to mitigate circular dependencies.

Approaches to representing nested views

• Case 1: Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)
• Case 2: View exposes packages with views
• Case 3: View contains nested views

Example (representing nested parts tree). The default case is to apply the same rendering method to each element. In effect, the rendering method and filter is inherited by all elements in the view.

Case 1. Specify view rendering for each element in the view (e.g., show nested parts as a tree view for some parts and interconnection view for others)

Case 2. View exposes packages with views

Case 3. View contains nested views

How a view/query is performed when using a view as an input mode is unspecified.

This should be clarified and added.

Add standardized element icons and standard view definition icons as they should appear in a browser or on diagrams.

Specifications of the standard views in library StandardViewDefinitions.sysml are incomplete, i.e. they are not all formally specified with a filter expression.

Specify valid Definitions as a filter expression for each ViewDefinition. Initial specifications are in textual descriptions in clauses 9.2.19.2.x.

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

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

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

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

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

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

Comment_Mapping is missing a default rule locale

GenericToElement_Mapping is missing default rules for:

• owningRelationship
• aliasIds
• declaredShortName
• isImpliedIncluded

GenericToStateUsage_Mapping is missing a default rule for isParallel

GenericToRequirementUsage_Mapping is missing a default rule for reqId

GenericToRelationship_Mapping should provide default rules for

• owningRelatedElement
• isImplied

Any execution of the CommentAnnotation_Mapping transformation rule shall result in the same instance of SysMLv2 Annotation for a given (Comment, annotatedElement) pair provided. I.e. it should specialize the Foundations::UniqueMapping class.

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.

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

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

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

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

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

There should be a Constants Domain Library that capture all mathematical and CODATA Fundamental Physical Constants as published on https://pml.nist.gov/cuu/Constants/, in particular from the ASCII list of all constants at https://pml.nist.gov/cuu/Constants/Table/allascii.txt. Each constant should include a specification of whether its real number value is exact or not and, if not, what the uncertainty is.

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.

Clause 8.3.16.5 (AssignmentActionUsage), Description, says:

An AssignmentActionUsage is an ActionUsage that is defined, directly or indirectly, by the ActionDefinition AssignmentAction from the Systems Model Library. It specifies that the value of the referent Feature, relative to the target given by the result of the targetArgument Expression, should be set to the result of the valueExpression.

but does not require the model to specify when the expression is evaluated (or its owner, AFAICT).

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

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

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

Currently, the transformation supports only AcceptEventActions with one trigger, but it could be many.

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

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

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

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.

In SysML 1.7, Clause 10.1 (Overview, Constraint Blocks) and 10.3.2.1 (ConstraintBlock) say:

Constraint blocks define generic forms of constraints that can be used in multiple contexts. For example, a definition for Newton’s Laws may be used to specify these constraints in many different contexts. Constraint blocks can be used to specify a network of constraints that represent mathematical expressions such as {F=m*a} and {a=dv/dt}, which constrain the physical properties of a system.

A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block typically defines one or more constraint parameters, which are bound to properties of other blocks in a surrounding context where the constraint is used.

enabling an equation to "calculate" any of its variables (constraint parameters), to the extent it's reversible, depending on its usage. For example a constraint block for F=m*a can calculate any on of its variables given the other two by where it's used. But in SysML v1 to SysML v2 Transformation, 7.8.5.2.1 (ConstraintBlock_Mapping) says

A SysML::ConstraintBlocks::ConstraintBlock is mapped to a SysML v2 ConstraintDefinition. The following shows an example of what the textual SysML v2 syntax of the result of the transformation may look like.

onstraint def SysMLv1ConstraintBlock {
in attribute a : ScalarValues::Integer;
in attribute b : ScalarValues::Integer;
in attribute c : ScalarValues::Integer;
constraint constraintExpression {
  language "OCL2.0"  /* c == a + b */ } }

suggests constraint parameters are mapped to attributes with direction in, preventing them from being "calculated" from within the constraint (see KERML-10).

Not sure if the above is encoded in the mapping rules, but perhaps related is 7.8.5.2.2 (ConstraintParameter_Mapping), under Mapping Rules, says

The mapping class only has inherited rules. See the mapping classes in the general mapping section for details.

which means nothing specific is required for mapping constraint parameters. I couldn't find a "general mapping section".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The transformation does not include a mapping for UML4SysML::GeneralizationSet.

The transformation does not consider the property UML4SysML::RemoveVariableValueAction::isRemoveDuplicates.

There is a machine-readable file containing the example model described in Annex A, but only in the textual notation. There should also be machine-readable versions of this model represented in XMI and JSON.

Clause 7 Language Description includes a large number of example models and snippets, in textual and graphical notation. However, no machine-readable interchange file was submitted for these models. Project interchange files should be provided for them, including textual notation, XMI and JSON versions.

Multiplicities and bound values of redefining features don't seem to show up in the specification. For example, Clause 9.7.3.2.40 (Toroid) redefines edges, faces, and genus, but does not show the redefining multiplicities or bound values that appear in ShapeItems.kerml and the repository from which this part of the spec was generated. Might be other kinds of information missing on other redefining features.

Project interchange files (.kpar) were submitted for all model libraries. However, in all cases, these archives only included textual notation model interchange files (.sysml). There should also be normative model library project interchange files in which the models are formatted in XMI and JSON.

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.

The SysML v2 RFP included Requirement PRP 1.15 “Probabilistic Value Distributions", which stated:

Proposals for SysML v2 shall include a capability to represent the value of a quantity with a probabilistic value distribution, including an extensible mechanism to detail the kind of distribution, i.e. the probability density function for continuous random variables, or the probability mass function for discrete random variables.

This requirement was not satisfied in the SysML specification as submitted. A capability should be added that covers this requirement. It should at least be possible to represent a numerical value as a symmetric or asymmetric accuracy, uncertainty or tolerance, with a uniform (i.e., rectangular) distribution.

Explicit concepts for ratio, RatioValue and RatioUnit are missing from ISQ and SI, although they are highly relevant and often used.

Similarly fraction, FractionValue and FractionUnit would be useful.

Add these concepts as specializations of DimensionOneValue and DimensionOneUnit.

Also add units <'%'> percent, <ppm> 'parts per million', <pbm> 'parts per billion'. For parts per billion it is important to explicitly chose the US or UK billion (10^9 vs 10^12).