In subclause 8.2.3.13 productions for n-ary ConnectionDefinition should be added, similar to the existing production n-ary-connection for n-ary ConnectionUsage.

An n-ary ConnectionDefinition example is given in 7.13.1 Table 11 in row "Connection Definition (n-ary with 3 ends)", like so:

The fourth and sixth rows of "Table 16. States – Representative Notation" each give an example of a transition statement that contains both an if statement and an accept statement, with the accept before the if.

...
transition
   first state1
   accept trigger1
   if guard1
...

However, page 110 and the subsequent examples seem to contradict this:

A transition usage can also have an accepter, which is an accept action usage use to trigger the transition. The

accepter action for a transition usage is placed after the guard expression and notated using the accept keyword,
with its payload and receiver parameters specified exactly as discussed in 7.16.8 .

If an accept before an if has a different meaning than an if before accept, the specification document does not make this obvious.
The Jupyter Kernel in release 2024-05 of the SysML-v2-Release repository treats an if before an accept as a syntax error.

On one hand abstract syntax chapters for the transitions between states stipulate (Figure 32 in 8.3.17.1@page316, text in 8.3.17.9@page325)
that transition can have multiple triggers, multiple guards and multiple effects
by specifying multiplicities [0..*] for TransitionUsage::triggerAction, TransitionUsage::guardExpression, TransitionUsage::effectAction

On the other hand, semantics and textual syntax chapters for the transitions between states stipulate (8.4.13.3@page424, 8.2.2.17.3@page178)
that transition can have at most one of each trigger, guard and effect
by stating:
"A TransitionUsage is parsed as having the following ownedMemberships
....
Zero to three TransitionFeatureMemberships for up to one each of a triggerAction, guardExpression, and effectAction."

and by using "?" marks (which has a meaning of [0..1] multiplicity) in the BNF
"TransitionUsage =
...
ownedRelationship += TriggerActionMember )?
( ownedRelationship += GuardExpressionMember )?
( ownedRelationship += EffectBehaviorMember )?"

-----------------------
This contradiction should be resolved in one direction or another - by stipulating either [0..1] or [0..*] everywhere.

We suggest that the variant with singular multiplicity be adopted as this seems to be closer to the original intent of standard builders.
This was also the convention of previous standards (UML)

Therefore the abstract syntax chapters - Figure 32 in chapter 8.3.17.1@page316, and specification in chapter 8.3.17.9@page325 -
should be updated with multiplicity [0..1] for the aforementioned 3 fields.

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.

According to the constraint checkStateUsageExclusiveStateSpecialization (in 8.3.17.6), a substate of a non-parallel owning state definition or usage must specialize StateAction::exclusiveStates (at least according to the description of the constraint; the OCL is wrong, see SYSML2_-183). However, the feature StateAction::substates actually meets the requirements for the application of checkStateUsageExclusiveSpecialization, which means that it has an implied specialization of exclusiveStates. But exclusiveStates already subsets substates (at least according to the library model in States.sysml; the feature exclusiveStates seems to be missing from subclause 9.2.10.2.1 StateAction), so this would mean that all substates are exclusiveStates, which is, of course, incorrect for the semantics of parallel states.

The resolutions by the KerML FTF to the following issues make restrictions to the functionality of imports in KerML and hence, by reference, in SysML, also:

• KERML_-73 Disallow public imports at root level
• KERML_-74 Make imports private by default
• KERML_-75 Restrict the functionality of recursive import

The discussion of imports in Clause 7 Language Description need to be updated to reflect these changes (particularly in 7.5.3 Imports). In addition, adopting the requirement to always show visibility of imports in the concrete syntax, consistent with KERML_-74, requires changes in

• 8.2.2.5.1 Packages (textual notation)
• 8.2.3.5 Namespaces and Packages Graphical Notation
• 8.3.5 Namespaces and Packages Abstract Syntax, Figure 5 Namespaces

The Systems Library model AnalysisCases includes a declaration for AnalysisAction as a specialization of Actions::Action. In the abstract syntax, ActionDefinition::analysisSteps and ActionUsage::analysisSteps are derived to be the subactions that are AnalysisActions.

However, no special semantics are specified for AnalysisActions and no special concrete syntax for defining analysisSteps. So they are never used in practice within user models of analysis caes, so they seem pointless.

Certain primitive data types have have specified extents of values

two "have"s remove one

This table has two rows where the Element Column states Enums Compartment. Recommend adding information to the row titles to indicate what aspect of the compartment is important. E.g., Enums Compartment (enumeration usage names) and Enums Compartment (enumeration values). Alternatively, combine these into one row.

"State with entry, do and exit actions." - code shows "entry actio1" instead of "entry action1"

"State with entry, do and exit actions": image showns definition by StateDef1, textual notation does not show this.

in SysML v1 there is a concept of Complete in terms of Specialization of a GeneralizationSet... that concept seems to be missing in SysML v2

a classifier in SysML v1 can have isFinalSpecialization:Boolean ... that concept is missing in SysML v2

in SysML v1 a RedefinableElement can have a isLeaf:Boolean... this concept seems to be missing in SysMLv2

in SysMLv1 for an ElementImport one can supply an Alias... That seems to be missing in SysMLv2

In the Geometry Domain Library model ShapeItems, in the item definitions CircularDisc, Sphere, CircularCone and CircularCylinder, the radius feature is bound to semiMajorAxis (or semiAxis1 for Sphere). However, because of the constraint featureValueOverriding, this means that the radius features cannot be re-bound to specific values in user-model usages of these definitions, as would be expected. (Note that this can only be seen in the ShapeItems.sysml file, not in the description in the specification document.)

The coexistence of both the "GenericTo*_Mapping" classes and the Initializer classes generates a significant number of redundancies in the model, and make it harder to understand and to maintain.

More specifically it makes the management of redefinitions much more complex with a very negative impact on the clarity of the specification.

In order to fix that, all the GenericTo*_Mapping classes shall be removed and replaced par their Initializer class equivalent in an appropriate way.

The mapping of ObjectFlow in combination with DecisionNodes including the decisionInput is not covered yet by the transformation.

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

In SysML v1, an output value of an action that is an input value of more than one action, is often modeled by an object flow and fork node which create object tokens pointing to the value.

The mapping of ObjectFlow in combination with ForkNodes is not covered yet by the transformation.

The mapping of ObjectFlow in combination with JoinNodes is not covered yet by the transformation.

In clause 8.2.3.25 view-frame is specified as a box with sharp corners and a UML / SysML v1 style name compartment.
Since views are usages, their notation should use rounded corners. Also, the '«view»' metaclass name is missing from the graphical symbol.

Affected view examples in the representative graphical notation tables in clause 7.25.5 table 24 should be made consistent with the graphical BNF specification.

Name textual expressions in GBNF for definition and usage names, exclude various characteristics such as specializations, redefinitions multiplicity etc.
Name expressions denoted definition-name-with-alias and usage-name-with-alias in GBNF, should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.

In the following example:

enum def Enum2 :> ScalarValues::Integer {a=1; b=2;}
attribute x1 : Enum2 = Enum2::a;
attribute x2 : Enum2 = 1;
attribute x3 : Enum2 = 42;

x3 is invalid, but currently, there is no validation for it.

Mr. Ed Seidewitz wrote:
x3 is semantically invalid, since 42 is not a legal value for Enum2, but there is currently no static validation check for it. This cannot be checked statically in general, because the bound value could be any expression returning an Integer, the value of which may not be determinable without doing a complete execution/evaluation of the model (we don’t currently have a general way to report “runtime” semantic errors like this, other than that the model will be formally “unsatisfiable”). It might be possible to add a validation constraint for the case in which the both the enumerated values and the bound value in the attribute usage are model-level evaluable expressions (which would catch the case of your x3), though the OCL could be a bit complicated. If you think it is worth it, you could file a SysML v2 Jira issue for this, though it probably not be addressed in the FTF (though we could possibly address it on the KerML side when resolving KERML_-245 to add enumeration syntax to KerML).

Current GBNF uses the textual notation to represent state entry/do/exit actions within a "state actions" compartment.
This does not allow to describe state actions in a graphical way and also requires the graphical modeler to use more extended textual syntax.

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.

The description of message declarations in 7.13.6 Flow Connection Usages and Messages is incorrect. It states that a message declaration "may or may not include identification of source and target related features. If they are included, then they follow the payload specification (if any), with the source related feature identified after the keyword from, followed by the target related feature after the keyword to." However, the from and to features of a message are not the related features of the message as a flow connection usage. Rather, they are the values of the sourceEvent and targetEvent parameters of the MessageConnection (see parsing in 8.2.2.13.4 Message and Flow Connections and semantics in 8.4.9.6 Flow Connection Usages).

In light of this, the message declaration example in 7.13.6 is also incorrect, as is the textual notation for the first "Messages" example in Table 11 Connections – Representative Notation (showing a message between ports). However, the graphical notation in this example seems to be acceptable, as are both the graphical and textual notations in the second "Message" example (showing a message on a sequence diagram).

1. In 7.25.1 Views and Viewpoints Overview, Table 23. Views and Viewpoints – Representative Notation, the example for "Expose" renders the expose relationship using a dashed arrow. However, in 8.2.3.25 Views and Viewpoints Graphical Notation, the graphical BNF production expose-relationship shows the arrow as being solid.
2. An expose relationship is a kind of import and, as such, can expose a single membership or the content of a namespace, and can optionally be recursive. The textual BNF production Expose in 8.2.2.25.2 View Usages allows all these options, as does the graphical BNF production expose-compartment-element (for showing an expose declaration in a compartment) in 8.2.3.25 Views and Viewpoints Graphical Notation. However, the graphical graphical BNF production expose-relationship does not.
3. The textual BNF production Expose allows a VisibilityIndicator on an expose declaration, as does the graphical BNF production expose-compartment-element. However, the graphical BNF production expose-relationship does not.

The mapping given in 9.2.21 from the MOF abstract syntax model to the reflective SysML abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative SysML.sysml file.

The KerML specification contains guidance for tooling to highlight keywords in concrete textual notation. KerML subclause 8.2.2.6 specifically says:

Tooling for the KerML textual notation should generally highlight keywords relative to other text, for example by using boldface and/or distinctive coloring. However, while keywords are shown in boldface in this specification, the specification does not require any specific highlighting (or any highlighting at all), and KerML textual notation documents are expected to be interchanged as plain text (see also Clause 10 on Model Interchange).

A similar statement, modified for SysML, should be added, probably as a last paragraph under subclause 8.2.2.1.2, including a cross-reference to KerML. For SysML the same guidance applies to textual snippets used in the Graphical Notation.

In the SysML Specification, 9.2.6.2.4 connections, the base connection usage connections is specified as being a ConcernUsage under "Elements". This should, instead, be ConnectionUsage. (Note that this error is only in the document, and connections is declared correctly in the Connections.sysml model file.

The following example appears in 7.8.2 Enumeration Definitions and Usages:

enum def ConditionColor { red; green; yellow; } 
attribute def ConditionLevel {
    attribute color : ConditionColor; 
}
enum def RiskLevel :> ConditionLevel {
    enum low { color = ConditionColor::green; } 
    enum medium { color = ConditionColor::yellow; } 
    enum high { color = ConditionColor::red; }
}

This is example is not valid, because the color features defined in the enumerated values will have name conflicts with the color feature inherited from ConditionLevel. The intent was probably to have the color features in the enumerated values redefine ConditionLevel::color, but that is currently missing from the example.

In 8.3.17.6 StateUsage:

1. The constraint checkStateUsageExclusiveStateSpecialization has the description

   A StateUsage that is a substate usage with a non-parallel owning StateDefinition or StateUsage must directly or indirectly specialize the StateUsage States::State::exclusiveStates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being parallel (rather than non-parallel) and requires specialization of substates rather than exclusiveStates.

2. The constraint checkStateUsageSubstateSpecialization has the description

   A StateUsage that is a substate usage with a owning StateDefinition or StateUsage that is parallel must directly or indirectly specialize the StateUsage States::State::substates from the Systems Model Library.

   However, the OCL for the constraint actually checks for the owning state being non-parallel (rather than parallel).

3. The operation isSubstateUsage used in the above constraints has the description

   Check if this StateUsage is composite and has an owningType that is an StateDefinition or StateUsage with the given value of isParallel, but is not an entryAction or exitAction. If so, then it represents a StateAction that is a substate or exclusiveState (for isParallel = false) of another StateAction.

   However, the OCL for the operation actually does not check if the state usage is composite and also excludes do actions (in addition to entry and exit 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.

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?

Add support for defining a metadata definition using the normal definition symbol (e.g., key word metadata def with metadata def name in name compartment). Separate compartment for attribute declarations. Add compartment redefined the annotated elements so they are constrained to be of a certain metaclass. (Note that MetadataDefinition is a kind of ItemDefinition but MetadataFeature (and therefore MetadataUsage) is a kind of AnnotatingElement.)

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 .

Throughout the document, we need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

Throughout the document, need consistent and formal language; for the * character, use 'asterisk' instead of 'star' for the character *.

I raised a number of issues previously with regards to detailed/specific problems with the KerML textual syntax grammar.
A more general issue is that I find the grammar (as written) hard to digest.
It is not modular, and the chapters don't seem to relate fully to the Abstract Syntax packages.

I have created an alternative grammar, using a different grammar-syntax, that allows for modular definition of grammars.
I would like to offer you this.
However, I cannot attach files to this issue!
feel free to contact me if you would like me to provide them.

In summary, one can modularise the KerML grammar into a Kernel, Core, Root (groups/packages)
with each group/package containing 3-5 grammar modules and extension relationships to combine them.

I plan to do the same for the full SysML grammar (later).

According to the SysML abstract syntax (8.3.17.9 TransitionUsage), the source and target of a TransitionUsage must be ActionUsages. However, the textual notation (8.2.2.17.3 Transition Usages) allows sources and targets to be feature chains, which are parsed as a KerML Feature with FeatureChaining relationships to the chained Features, which are not ActionUsages.

In the SysML Specification, in non-normative Language Description subclause 7.6.3 Usages, it describes several conditions that, if meet, require a usage to have default multiplicity 1..1. However, there is no formal specification of this in the normative Clause 8 Metamodel.

According to the KerML specification, "Structures and behaviors do not overlap". Consistent with this, the approved resolution to KERML-43 added validations to disallow a structure from specializing a behavior and vice versa.

ConnectionDefinitions in SysML are kinds of PartDefinitions, which are (indirectly) kinds of KerML Structures. But FlowConnectionDefinitions are both ConnectionDefinitions and ActionDefinitions, and ActionDefinitions are kinds of KerML Behaviors. This means that FlowConnectionDefinitions are both Structures and Behaviors, violating the restrictions of KerML.

As a result, the specializations in the declarations of MessageConnection and FlowConnection in the Systems Library model Connections now violate the new validateStructureSpecialization and validateBehaviorSpecialization constraints added by the resolution to KERML-43.

A SysMLv1::InterfaceBlock is mapped to a SysMLv2::PortDefinition, but the owned SysMLv2::ConjugatedPortDefinition is not generated.

A state with several regions should be mapped to a parallel state.

1. In 8.3.6.4 Usage, the name of valideaUsageVariationIsAbstract should be validateUsageVariationIsAbstract.

GBNF and notation tables only cover a generic "loop action" which is not aligned with the textual syntax that has 3 specific structured actions:

• while loop action
• for loop action
• if/else action

Each one of the above has a specific textual syntax, that the graphical syntax should align with, to enable proper graphical modeling of actions.

The notation tables show various permutations of send/receive actions with various parameter options. They are all shown against a single simple textual example. It is unclear what is the purpose of rationale each permutation.
Graphical Examples need to align with corresponding text examples.

The InitialState should be mapped to an empty ActionUsage owned by a StateSubactionMembership relationship.

The transformation ignores the entry, do, and exit behavior of a state.

The graphical notation makes use of enclosing guillemets to mark up presentation of the metaclass as well as possible metaproperties and metamodel extensions of a model element (i.e., their mapping to the SysML abstract syntax or metamodel). However, there are inconsistencies in their application. The following graphical BNF productions are affected:

• -name-compartment productions,
• -edge and -relationship productions,
• productions including user-defined keywords that extend the metamodel.

Currently, metaproperties of a metaclass are treated in different ways. E.g. in a -name-compartment the isAbstract metaproperty is presented as a leading '«abstract»' literal with its own guillemets, while the isReference metaproperty is included in the main metaclass presentation, e.g., '«ref part»'.

A single, consistent rule should be established for all graphical BNF productions that concern presentation of metamodel information.

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

The following cases in the textual notation allow "shorthand" then notations for SuccessionAsUsages:

1. In 8.2.2.9.3 Occurrence Successions, the production SourceSuccession creates a SuccessionAsUsage that has a source end with no related feature and no target end.
2. In 8.2.2.16.7 Action Successions, the production TargetSuccession creates a SuccessionAsUsage that has a source end as in SourceSuccession, but it has a full ConnectorEndMember for its target end, including an explicit related element.

In both cases, the intent is that the implied related feature of the source end of the SuccessionAsUsage is a feature lexically previous to the declaration of the SuccessionAsUsage. In the first case, the implied related feature for the target end of the SuccessionAsUsage is a feature lexically following the SuccessionAsUsage. However, there are no semantic constraints given in 8.3.13.8 SuccessionAsUsage to enforce these implied relationships.

In the SysML v2 the graphical notation for use cases is a box with rounded corners containing the stereotype "use case" and the use case name.
From the very beginning of UML and SysML v1.x use cases are visualized as elliptic elements. Nearly all people that have ever used or seen UML or SysML in the past are familiar with that notation. So why change it for SysML v2 here? It is not necessary from my perspective.
A box with many textual things inside is not a good idea for a graphical language. Graphical languages should use as less text as possible. Instead they should use different graphical shapes, different stroke widths, stroke types and icons to express the semantics and what is modeled.
A user should be able to recognize a diagram element on a first side, looking at a diagram drawing form far away. It should not be necessary to read all details to recognize that is a use case diagram and not any other diagram by reading the stereotype text elements first!

The reuse of KerML BNF productions in the SysML textual notation grammar is not described sufficiently. It is not clear which productions are reused and which not. Reused productions are simply missing from the SysML definitions.

(This issue was originally reported as part of SYSML2-635.)

The genera textual notation for (binary) connections (see 8.2.2.13.1 Connection Definition and Usage) allows for both a "short form" (connect...to...;) and a "long form", in which the ends are explicitly declared within the connection body. The notations for binding connections (see 8.2.2.13.2 Binding Connectors) and successions (see 8.2.2.13.3 Successions) also have their own "short forms" (bind...=...; and first...then...;)). However, even though both notations allow for connection bodies, the short-form part is required, so it is not possible to declare the ends within the bodies. (Note that the corresponding KerML notations do allow fully "long form" declarations for bindings and successions; see 8.2.5.5.2 and 8.2.5.5.3 in the KerML specification.)

The direction of a PortUsage can be specified like that of any other feature. However, this does not really seem to make sense. The direction of a PortUsage should be determined by the direction of features within it, consistent with the visualization of directions on ports shown, e.g., in the Representative Notation table in 7.11.1 Parts Overview.

[From Mr. Ryan Noguchi] In the SysML v2 spec, section 7.8.1:

An enumeration definition may not specialize another enumeration definition. This is because the semantics of specialization require that the set of instances classified by a definition be a subset of the instances of classified by any definition it specializes. The enumerated values defined in an enumeration definition, however, would add to the set of enumerated values allowed by any enumeration definition it specialized, which is inconsistent with the semantics of specialization.

To comply with the Liskov Substitution Principle, a specialization of an enumeration definition should only remove literals, not add them. Why can’t the specialization’s definition either simply remove existing literals from the general definition or list the applicable literals—resulting in a syntax error if this list includes anything not present in the general definition? As a concrete example:

enum def ClassificationLevel {
   enum unclassified;
   enum cui;
   enum secret;
   enum top_secret;
}

enum def ClassificationLevelClassified :> ClassificationLevel {
    enum secret;
    enum top_secret;
}

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

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

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

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

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

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

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

A requirement should include a text body to capture the shall statement or other human readable requirement statement. The doc annotating element is one way to accomplish this. However, a doc element on a requirement definition is inherited by its requirement usages, but it cannot be redefined on its usage. (Note: The texts of a RequirementUsage are the bodies of the documentation of the RequirementUsage.)

The proposal is to add a distinguished attribute to capture the text body of a requirement that would replace the derived text attribute/documentation. This distinguished attribute can be redefined. This avoids a requirement usage from having both the original text in the requirement definition and the modified text in the usage.

The concrete syntax should be updated accordingly.

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

According to the SysML Specification, 8.2.2.16.4 Send and Accept Actions, the general textual notation for a send action has the form

send payloadExpression via senderExpression to receiverExpression

In this syntax, the via and to parts are optional, but the payloadExpression is not. Since the result of the required payloadExpression is bound to the payload parameter of the send action, this makes it difficult to model a case in which, e.g., it is desired use a flow to provide the value of the payload, rather than the result of an expression. It also makes it difficult to model a general send action with the payload not specified (or defaulted), with the actual payload bound in a specialization of the general action.

While it is possible to get around these limitations by modeling the send action using a regular action usage typed by Actions::SendAction, this is no longer syntactically a send action usage and so, e.g., would not be rendered as such in the graphical notation. It would be better if the textual notation allowed the payloadExpression to be optional, while still declaring syntactic send action usage.

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

GenericToStateUsage_Mapping is missing a default rule for isParallel

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

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

GenericToElement_Mapping is missing default rules for:

• owningRelationship
• aliasIds
• declaredShortName
• isImpliedIncluded

Comment_Mapping is missing a default rule locale

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

GenericToRelationship_Mapping should provide default rules for

• owningRelatedElement
• isImplied

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.

GenericToRequirementUsage_Mapping is missing a default rule for reqId

Clause 8.4.5.2 (Occurrence Usages) says

If an OccurrenceUsage has a non-null portionKind, then it is also required to have a portioningFeature with the same portionKind. The following semantic constraints apply to a PortioningFeature:
...

and the code example at the end of 8.4.5.2 has comments identifying some features as "Portioning", with text below it referring to portioningFeature

However, portioningFeature doesn't appear in Figure 12 (Occurrence Definition and Usage) or anywhere else in the document.

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

Definition elements incorrectly appear in graphical BNF productions for interconnection-element. Remove the following from interconnection-element productions: part-def in 8.2.3.11, port-def in 8.2.3.12, connection-def in 8.2.3.13, constraint-def in 8.2.3.19, requirement-def and concern-def in 8.2.3.20, viewpoint-def and view-def in 8.2.3.25.

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.

The intent of "initializer" classes is to factorize the opeations that provide default values for the properties of a target class so that it can be used for both mapping and factory classes. Initializers that do not generalize both a mapping and a factory class are useless and should be remove for clarity

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

The redefinition of ownedRelationship() is missing the "class" part, i.e. what is defined in its Class aspect

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

Informal specification of requirements is realized as body of the documentation.
Informal requirement specification often contains text formatting and images as illustrations. To facilitate exchange of requirements between different organizations and proper rendering, the used formatting language, the relative root path for included images and their allowed formats have to be aligned.

• add optional 'language' keyword to doc
• define the folder containing the sysml file as root for references made from documentation elements within this file

To provide guidance for users on common formatting

• reference jpg and png as suggested image formats
• reference markdown "md" or other low-complex language as suggested formatting language

example:
requirement def SomeRequirement

Concern_Mapping is a main mapping that calls ConcernOwningMemberships_Mapping in its ownedRelationship() operation, which itself calls ConcernDocumentation_Mapping. However, the one defined in its ancestor Comment_Mapping should do the job without them.
The redefinition should then be removed and both ConcernOwningMemberships_Mapping and ConcernDocumentation_Mapping are useless and should be replace by a simpler version of the ownedRelationship() operation.

In the textual notation, a change event can be represented by an accept action with a when condition. The example below is from the vehicle model.
transition normal_To_degraded
first normal
accept when senseTemperature.temp > Tmax
do send OverTemp() via targetPort
then degraded;

A UML4SysML::ConstraintProperty is currently mapped to a ItemUsage, but should be an AssertConstraintUsage.

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

Clause 7.13.3 (Bindings as Usages) says

The end features of a binding always have multiplicity [1..1].

and Clause 8.3.17.9 (TransitionUsage) includes a constraint requiring a (1 to 1) binding between its succession and transitionLink:

checkTransitionUsageSuccessionBindingConnector
A TransitionUsage must have an ownedMember that is a BindingConnector between its succession and the
inherited Feature TransitionPerformances::TransitionPerformance::transitionLink.
ownedMember->selectByKind(BindingConnector)->exists(b |
b.relatedFeatures->includes(succession) and
b.relatedFeatures->includes(resolveGlobal(
'TransitionPerformances::TransitionPerformance::transitionLink')))

with similar text in 8.4.13.3 (Transition Usages). A succession will typically have fewer values than its transition usage, because the succession won't be traversed for every value (occurrence) of its source feature, while its transition usage will have the same number of values as the source feature, conflicting with the 1-1 end multiplicities. Compare to the modeling pattern in KerML Clause 9.2.10.1 (Transition Performances Overview), excerpted in KERML-157.

Clause 8.4.12.4 (Control Nodes), under the Join and Fork headings says:

validateJoinNodeIncomingSuccessions constraint requires that all incoming Successions to a JoinNode have source multiplicity 1..1.

validateForkNodeOutgoingSuccessions requires that all outgoing Successions from a ForkNode have target multiplicity 1..1.

but the validation rules are missing from 8.3.16.11 (JoinNode) and 8.3.16.8 (ForkNode), respectively.

In the textual notation, a time event can be represented by an accept action with an at or after condition. The example below is from the vehicle model.
transition normal_To_maintenance
first normal
accept at maintenanceTime
then maintenance;

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.

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.

The representative notation example "Package with members compartment" shows the members compartment which is the default compartment and does not require a compartment label. Change members compartment label to the requirements compartment label and adjust the package content and textual notation accordingly, i.e. with requirement elements.

Decision/MergeNodes are (indirectly) typed by KerML:Decision/MergePerformance (via specialization of Actions::Action::decisions/merges), which KerML Clause 9.2.9.1 (Control Performances Overview) requires:

Successions going out of Steps typed by DecisionPerformance or its specializations must:
• ...
• be included in a Feature of its featuringBehavior that unions (see 7.3.2.7) all the outgoing Successions, and is bound to the outgoingHBLink of the Step (see 7.3.4.6 on feature chaining).

Successions coming into Steps typed by MergePerformance or its specializations must:
• ...
• subset a Feature of its featuringBehavior that unions all the incoming Successions, and is bound to the incomingHBLink of the Step.

while constraints in 8.3.16.7 (DecisionNode) and 8.3.16.13 (MergeNode) say

checkDecisionNodeOutgoingSuccessionSpecialization
All outgoing Successions from a DecisionNode must subset the inherited outgoingHBLink feature of the DecisionNode.
sourceConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::outgoingHBLink")))

checkMergeNodeIncomingSuccessionSpecialization
All incoming Successions to a MergeNode must subset the inherited incomingHBLink feature of the MergeNode.
targetConnector->selectByKind(Succession)-> forAll(subsetsChain(this,
resolveGlobal("ControlPerformances::MergePerformance::incomingHBLink")))

with similar text in 8.4.12.4 (Control Nodes) under Decision / Merge Nodes. These constraints allow outgoing/incomingHBLink to have values that are not identified by outgoing/incoming successions when none of the successions is traversed. The KerML pattern above introduces a feature unioning the successions and binds it to a chain through decision/merge to outgoing/incomingHBLink, ensuring the HB links are identified by the successions. See Annex A.3.7 (Timing for behaviors, Decisions and merges) for an example, at the end of the model to be executed (first code listing), under "Decision and merge timing constraints".

Add feature modifiers (e.g. ordered for [1..*] timestamps) to "Portion Membership" examples in representative notation tables for Occurrences.

In examples "Individual Occurrence", "Timeslice", "Snapshot", add attribute to «individual» «occurrence» and redefine the attribute with value in «timeslice» and «snapshot».

Add example package with filter in 7.5.1. The filter should be one of the filters defined in 9.2.19.2.4. Good choice is filter for Requirement.

Add feature modifiers (e.g. ordered, nonunique) to "Feature Membership" examples in representative notation tables for Definitions and Usage.

Example "Package with imported packages (nested packages)" should use dotted instead of dashed outline

Add import qualifier text (* or **) to upper right corner of imported Package

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

Clarify that the identifier for the metadata declaration is the metadata definition name.

Add graphical notation to represent binding between action inputs and outputs and directed features on ports.

The request is to add a representative notation example to Table 11 that shows how directed features of performed actions in parts can be connected to directed features of ports.

Add representative notation for causation (9.5.2.1) and requirements derivation (9.6.2.1) including n-arys. This (and other representative notation examples for domain library models) should probably go into the respective 9.x Overview subclauses, rather than in Clause 7.

The transformation does not map the Parameter::isStreaming.

The mapping of a Unit and a QuantityKind is not covered by the transformation yet.

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

There are a number of cases in which derived properties require that a referenced feature by of a certain metaclass. For example, the EventOccurrenceUsage::eventOccurrence property is derived as the referencedFeature of the ownedReferenceSubsetting EventOccurrenceUsage (if it has one), but the property is typed as an OccurrenceUsage, so the referencedFeature must be an OccurrenceUsage. This is enforced by the validateEventOccurrenceUsageReference constraint.

Unfortunately, this does not take feature chaining into account. If the referencedFeature has a feature chain, it will be parsed as a plain Feature, not an OccurrenceUsage. However, the last Feature in the chain should be an OccurrenceUsage, and this OccurrenceUsage is what should be the eventOccurrence of the EventOccurrenceUsage, and what is check by validateEventOccurrenceUsageReference.

There are similar problems with at least the "reference" derivation and validation constraints for all the subtypes of EventOccurrenceUsage, and perhaps in other cases, too.

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

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

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

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

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

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

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 are different implementations of the SysML v2 graphical notation in the various release documents

Documents checked:
2-OMG_Systems_Modeling_Language.pdf Version 2.0 Release 2023-02
Intro to the SysML v2 Language-Graphical Notation.pdf (2023 03 07)
Intro to the SysML v2 Language-Textual Notation.pdf Release: 2023-02

Example of difference, on page 218 of "2-OMG_Systems_Modeling_Language.pdf", the stereotype identifier (<<state>>) is not displayed for State1 and State2, in the "Intro to the SysML v2 Language-Graphical Notation.pdf", the "<<state>>" is displayed.

If you then take a look at the "Intro to the SysML v2 Language-Textual Notation.pdf" document, there is again a different graphical notation.

What is the correct standard notation? Does the "2-OMG_Systems_Modeling_Language.pdf" take precedence here?

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

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

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.

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

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.

Package-level features do not give featuring types, and some have lower multiplicity greater than zero, meaning everything in the universe (instances of Anything), including every data value, is required to give at least that number of values to them (see KERML-56). For example, the libraries include:

Time::universalClock[1] {...} 
Observation::defaultMonitor[1] : ChangeMonitor[1] {...}
SpatialFrames::defaultFrame : SpatialFrame[1] {...}

Might be others.

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

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

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