In subclause 8.2.3.10 the production item-name-compartment is out-of-date. In line with other usage name-compartment productions it should read:

item-name-compartment =
      '«' OccurrenceUsagePrefix 'item' '»'
      usage-name-with-alias

In subclause 7.13.1, Table 11, example "Flow as Node" the subitems of parameters item1 and item2 of the flow between action1 and action2 are depicted in the elaborated flow node with parameter symbols subItem1, subItem2, subItem3. The current graphical notation is as follows:

Currently parameter nodes can only show nested parameters and direction. They need to be able to show owned features such as item usages.

In clause 7.16.1, the examples provided for send action are confusing and erratic. 5 alternative graphical examples for a single textual reference shown all of them have issues.

• First example might be correct, if payload is indeed a parameter
• Second example simply partial and lacks information such as picture
• 3rd example use guiileimets in the textual expression and has redundant parameter symbols
• 4th example Show(shoot.picture) misaligned with textual example
• 5th example is partial and ot equivalent to the textual reference

Clause 7.16.1 (rep. notation for actions) shows a graphical notation example of an accept action corresponding to the following textual notation:

action trigger1 : Trigger 
accept scene : Scene via viewPort;

It shows 3 alternative graphical notations which are confusing and inconsistent.
That graphical representative example needs to be corrected. Here are few issues:

• it shows an unbound parameter "receiver" in 2nd and 3rd examples
• first example uses the type Trigger instead of Trigger1
• 3rd example uses guillemets in the wrong way
• too many options instead of one "canonical" way to do this
• it uses a parameter that in 2nd example called scene and in 3rd example called payload

In subclause 7.9.1., Table 7, examples "Individual Occurrence" and "Portion Membership" the graphical notations incorrectly show «individual» as a separate keyword in guillemets. In line with the Graphical BNF specification, they should be put together with the main element keyword, i.e. «individual occurrence» and «individual part» respectively.

The first example also contains a typo: 'OccurenceDef1-1' should read 'OccurrenceDef1-1'. The second contains typo: indvidual1 should read individual1.

The COAPin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.

Operation RICOAOutputPin_Mapping::filter() does not redefine Pin_Mapping::filter(). The issue is not visible in the specification document but in the model resp. XMI.

The subclause 7.7.5.3.7 Trigger_Mapping contains no text.

In subclause 7.9.1, Table 7, example "Individual Occurrence Definition", in the graphical notation, the name 'OccurenceDef1-1' is an UNRESTRICTED_NAME and should be written between two single quotation marks as it contains a character (the hyphen) outside the valid character set for BASIC_NAME (see KerML clause 8.2.2.3).

There are also many typos in the spelling of "occurrence":

• Example "Occurrence Definition": in graphical notation OccurenceDef1 should read OccurrenceDef1.
• Example "Occurrence": in graphical notation OccurenceDef1 should read OccurrenceDef1.
• Example "Individual Occurrence Definition": In graphical notation: OccurenceDef should read OccurrenceDef (2x missing r), and in the textual notation: OcurenceDef should read OccurrenceDef (1x missing c).
• Example "Individual Occurrence": in graphical notation OccurenceDef1-1 should read OccurrenceDef1-1.
• Example "Timeslice": in graphical notation OccurenceDef1 should read OccurrenceDef1.
• Example "Snapshot": in graphical notation OccurenceDef1 should read OccurrenceDef1.

The graphical BNF and representative notation do not support an else branch originating from a decision node.

general-view is used but not specified. The definition should probably be

general-view = 
    definition-node*  definition-edge * usage-node* usage-edge*

Also, need to add a production for definition-edge and account for namespace symbols (e.g., packages)

While there is a production for a diagram frame, it is not used by the graphical BNF, other than by "usage-node".
There is a need to specify how diagram frames are integrated into the various view productions, such as general-view, interconnection-view etc

In subclause 7.13.1, Table 11, example "Flow as node" in the «flow» elaboration symbol the subItems of source.item1 and target.item2 are depicted with parameter symbols. This is incorrect because the subItems are undirected features and therefore should be depicted as parameters, but rather as nested items inside the containing item1 and item2 rounded rectangles.

In subclause 7.17.1, Table 16, example row "State with entry, do and exit actions", the compartment label is "actions".

In subclause 8.2.3.17 in production state-actions-compartment the compartment label is "states".

To be explicit and unambiguous, in both places the label should be "state actions".

In clause 7.16.1 Table 14 examples "Actions Compartment" and "Perform Actions Compartment" have outdated notation using parentheses for parameter notation in actions compartments.

It is suggested to remove those parameter declarations.

The specification of Helper::getScalarValueType() uses the unknown OCL String function includes:

t.qualifiedName.includes('PrimitiveTypes::UnlimitedNatural')

To check if a string is part of another string, the function indexOf() should be used instead.

The issue was accidentally introduced by SYSML2_-300 in ballot #3.

The ValuePin_Mapping class should specialize directly or indirectly a mapping class from the mapping framework. Very likely, it should specialize Pin_Mapping.

The mapping class AEAChangeParameterFeatureMembership_Mapping is in the transformation model, i.e., the XMI and is referenced by the mapping class AEAChangeParameterTrigger_Mapping, but the description is missing in the document.

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

Some graphical symbols used in state machine diagrams and activity diagrams in SysML v1 have been informally carried over to SysML v2. However, there are inconsistencies in how the symbols are used in SysML v2 actions and states. The intent is to align the symbols shown in the attachment that include the graphical SysML v2 symbols in action flow views that correspond to the initial node, flow final, and activity final with the SysML v2 graphical symbols in state transition views that correspond to the initial pseudo state, final state, and terminal node pseudo state. This will also require addressing the symbols for entry action which is currently informally depicted in SysML v2 with a solid filled circle like the initial pseudo state.

Issue 1: the following notation found in the middle of the page has a comma instead of a semicolon for the declaration of an "in".

action def B { in b1, out b2; }
should be
action def B { in b1; out b2; }

Issue 2: The following notation found in the middle of the page has the wrong kind of closing bracket, followed by a semi-colon, following the declaration of an action definition. I.e., a closed parenthesis and semi-colon should be replaced by a closed curly bracket.

action def B1 :> B { in b1; out b2; inout b3); // Redefinitions are implicit.
should be
action def B1 :> B { in b1; out b2; inout b3} // Redefinitions are implicit.

In 9.1 Model Libraries Overview, in the last paragraph, it states that "the prefix https://www.omg.org/SysML/" should be used "when constructing the URL for a standard library package" as part of the generation of model library element UUIDs. The URL used here should instead be the standard OMG base URI https://www.omg.org/spec/SysML/ (which was what was actually used when generating the UUIDs in the normative XMI for the library models).

The chapter 7.8.7.3.4 has no content.

The chapter 7.8.7.3.3 has no content.

The phrase "As such, any directed usages declared in the body of a calculation definition or usage are considered to be owned parameters of the calculation."
Should be corrected to say "As such, any directed usages declared in the body of a constraint definition or usage are considered to be owned parameters of the constraint."

An Actor is mapped to an ItemDefinition, but it should be a PartDefinition.

The temporary mapping classes

_InitialState_Mapping and _InitialStateMembership_Mapping

should be removed from the SysMLv1Tov2.xmi.

They are not part of the specification document.

Helper::getScalarValueType checks only the name of the input parameter and does not consider the fully qualified name to check if it is part of the SysML v1 library. Any DataType of name "UnlimitedNatural" is mapped to ScalarValues::Natural.

"A RenderingDefinition is a kind of PartDefinition. As such, all the general semantic constraints for a PartDefinition (see 8.4.7.1) also apply to a ViewDefinition."

Should be "RenderingDefinition" not "ViewDefinition"

spec: "A view definition or usage is declared as a kind of part definition or usage (see 7.11.2 ), using the kind keyword view. A view usage must be defined by a single view."

Should this be "single view definition"?

Issue 1: textual notation does not include a state definition, but the graphical notation does. Change to match.
Issue 2: textual notation has an assumed spelling error, also causing a mismatch to graphical notation. In the following notation, "actio1" should likely be "action1".

state state1

Readers should expect that the textual notation and graphical notation should match as much as possible, including element names.
The attributes compartment row should at least align on the attribute1 declaration (the definition is different between the graphical and textual notations. I would like to make the case that all of the graphical notation examples should be shown in textual notation, too. If it is worth it to show the graphical notation expectation in the table, it is worth it to show the corresponding textual notation.

Example of minimum correction in textual notation:
change:
attribute attribute1 : Attribute1Def
to:
attribute attribute1 : AttributeDef1

I suspect that there are two errors near the top of page 30 in the P8 namespace textual notation:
1. Import Annotations::*; should be import ApprovalMetadata::*;
import Annotations::* does not seem to serve a purpose here, and ApprovalMetadata elements would be needed to support the following code (when corrected).
2. import NA::*[@Approved]; should be import NA::*[@Approval and approved]; or import NA::*[@approved]; or another version of this depending on interpretation of preceding commentary.

There is an error in the last example on this page and in this section. One line calls out "comment Comment 2", which is likely intended to be "comment Comment2".
Suggest change from original: comment Comment 2
to: comment Comment2

The following row headers describe unowned elements, but the textual notation illustrates that the elements are owned.

Package with alias member (unowned)
Package with alias member (unowned)
Membership (unowned member with alias name)

The simplest resolution, if the desire to emphasize "unowned" is maintained, may be to use textual notation for each which declare the packages to be aliased in the next higher namespaces.

A sentence is missing a word indicating that an owned comment is implicitly about the element owning the namespace, if it is about nothing else:

Original: "If the comment is an owned member of a namespace (see 7.5 ), then the explicit identification of annotated elements can be omitted, in which case the annotated element is implicitly the containing namespace."
Should be:"...the annotated element is implicitly about the containing namespace."

In two SysML textual notation example snippets, (1) clause 7.16.4 third snippet, (2) clause 7.16.5 last snippet, a merge node is named loop. This is not allowed as loop is a keyword.

Suggest to rename the merge node to something like loopBegin, beginLoop or loopEntry.

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.

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.

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

It is possible to define flow connection usage in several ways.
One - use the simple/nice notation where syntactic sugar hides the underlying complexity:
flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the flow ends:
flow of SomeItemDefinition {
end ::> firstEndCon

end ::> secondEndCon {
:>>targetInput, someFlowPropertyofEnd2;
}
}

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

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

Pass-through note to Ed: This is one of the issues from the compiled list that we talked about - issue # SYSML2-2848 on DS side

Currently, the only way to create payload for flow def is to redefine it explicitly:
flow def SomeFD {
:>>payload: SomeData;
end :FirstEndType;
end :SecondEndType;
}

it would be nice for the same syntactic sugar "of TypeOfPayload" to be available for flow defs as is now available for flow usages:
flow def SomeFD of SomeData

Pass-through note to Ed: This is one of issues from the compiled list that we talked about - issue # SYSML2-2851 on DS side

It is possible to define flow connection usage in several ways.
One - use the simple/nice notation where syntactic sugar hides the underlying complexity:
flow of SomeItemDefinition from firstEndCon to secondEndCon;

Second- use full available detailed notation allowing precise definition of the characteristics of the payload
flow {
:>>payload: SomeItemDef; //note more characteristics for payload can be modeled here - especially useful when flows are inherited
end ::> firstEndCon;
end ::> secondEndCon;
}
Sometimes the second, detailed way is the only way to define characteristics of the payload in the more complex cases (especially when the flows are inherited/specialized in the hierarcy).

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

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

This non-uniformity causes several technical problems down the line
It does not allow to have other kind of features (for example ReferenceUsage in SysML) as item features on FlowConnections. ReferenceUsage is not inherited from ItemFeature
ItemFlow::itemFeature derived property returns only owned flow item feature, but in practice actual (owned or inherited) one should be returned.

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

Pass-through note to Ed: This is amalgamation of the couple of issues from the compiled list that we talked about - issues # SYSML2-1813 # SYSML2-2855 on DS side

If permitted, the transformation must also enable the mapping of SysML stereotypes that extend specialized metaclasses. For example, Satisfy based on Realization or Block based on Activity.

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.

In current implementation each FlowConnectionUsage owned by PartUsage subsets (automatically) 3 features:
FlowConnectionUsage::flowConnections
PartUsage::subparts
ActionUsage::ownedActions

This could be optimized for the sake of model size.
Maybe it would be better idea to introduce
Part::Part::ownedFlows :> ownedActions, subparts, flowConections
and define something like CheckFlowConnectionSubFlowSpecialization constraint?

Pass-through note to Ed: This is one of the issues from the compiled list that we talked about - issue # SYSML2-1758 on DS side

When metadata is defined with keyword textual notation allows short syntax of metadata application with #keyword.
Example from the spec:
occurrence def Situation;
occurrence situations : Situation[0..*] nonunique;
metadata def <situation> SituationMetadata :> SemanticMetadata {
:>> baseType = situations meta SysML::Usage;
}

// batteryLow is an OccurrenceUsage that implicitly subsets situations.
#situation occurrence batteryLow;

Unfortunately, the end user still needs to know underlying model element flavor (occurrence in the example above).
This knowledge is difficult to learn for the users of the particular specialized domain.
It could be considered an "implementation detail" of the domain specific modeling provider.

Idealy,
when metadata is defined 1) with keyword 2) with annotatedElement fixed to a single variant,
the end user should not need to specify the model element flavor ("metaclass") in the textual notation and just state the keyword; like this:
#situation batteryLow;

This would be very handy for UAF and other domains.

Pass-through note to Ed: This is one of the issues from the compiled list that we talked about - issue # SYSML2-2899 on DS side

These issues reported by Dovile.ZIAUKIENE from Dassault.
See 2 attachments.
1. Name compartment of a package does not support guilements modifiers

• a GBNF issue

2. Unowned member alias notation

• looks like a notation tables issue

The specification does not describe the else-condition for an outgoing succession of a decision node.

Graphical notation uses a caret symbol "^" to show inherited properties. This is currently only possible for textual compartments, it also needs to be enabled for name compartments.

An Operation should not be mapped to perform action, but an owned action.

In clause 8.2.3.5 graphical BNF production relationship-name has an incorrect body of comma-separated terminals.

It should use the pipe symbol as a separator instead of comma, i.e.:

relationship-name = 'defines' | 'defined by' | 'specializes' | 'specialized by' | 'connect to'
    | 'subsets' | 'subsetted by' | 'performs' | 'performed by' | 'allocated' | 'allocated to'
    | 'satisfy' | 'satisfied by'

There are a number of compartments in graphical notation that have misleading labels. For example, a "require constraints" compartment may contain besides pure "require ConstraintUsage" also "require RequirementUsage" statements. Similary, a "assume constraints" compartment may contain besides "assume ConstraintUsage" also "assume RequirementUsage". A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2).

This is a wider problem that potentially also applies to other qualified compartment labels. The full list of affected compartment label qualifiers is:

• assert
• assume
• exhibit
• include use cases
• perform
• require
• satisfy
• verify

In addition a mix of verb forms are used in compartment labels, some use the infinitive (satisfy requirements), some use third person singular form (satisfies). This is confusing and should be regularized in a consistent way, following a single rule.

To be more consistent across the section 7 tables in the specification, make the row headers of table 2 unique. From:
Comment
Comment
Documentation
Documentation

to something like:

Comment (stereotype hidden)
Comment (stereotype, name shown)
Documentation
Documentation with Name

There are two row headers which says "Interface". One of these showed more of a general/compartment view (no declared connection), while another shows more of an interfaces view (including a declared connection). Please make the headers more clear regarding what the reader should find.

E.g.:
Interface Usage
Interface with connection

This seems an odd choice and at least needs more explanation of how the various features of part definitions, like ports, are used

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

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

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

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

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

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

In 7.25.2 the spec says "A view artifact is an individual view usage where the model content is rendered in a compartment of the view usage"
View artifact is italicized so it is presumably significant but I don’t understand the sentence.

In section 7.25.1 on page 137, view artifact is defined thus: “A view artifact is a rendering of information that addresses some aspect of a system or domain of
interest of concern to one or more stakeholders”

Currently proxy connection points are supported by GBNF only for interconnection, action-flow, and sequence views. They should also be applicable in state-flow and possibly other views such as case and general views for additional usage nodes.

The UML specifies that a use case yields a

"result that is of value for Actors or other stakeholders".

In SysML 2 it now says

"The objective is to yield an observable result that is of value to one or more of the actors".

Stakeholders are no longer allowed. I think this would be necessary.

There are use cases, whose result is not of value for any of the actors. For example a prison cell. The inmate interacts with the cell, observes the result, but is most likely not seeing a value in it. The result is of value for the society, which is not an actor of the prison cell.

I suggest to add stakeholderParameter to the properties of UseCaseDefinition and UseCaseUsage.

Additionally, it should be possible to identify the actors or stakeholders, for whom the result is of value. It is from their view, that the objective is to be described. This information whould guide the documentation of the objective.

The Mappings overview tables presented in the specification document of the v1 to v2 transformations includes many consistency errors with regard to the mappings actually specified in other parts of the document. This in particular true for the overview tables in the "UML4SYSML" part.

The content of those tables is generated, so there are obviously issues in the corresponding algorithm.

Note that, since, the specification of the transformation itself is not the point here, and then will not be modified by the resolution, this issue can be considered editorial.

Although deprecated, FlowSpecifications are still part of SysML v1 and there should be a defined mapping for the element.

Although deprecated, FlowPorts are still part of SysML v1 and there should be a defined mapping for the element.

Table 13 shows an example of a composite allocation. Part allocation owns an allocation between performed actions.
The graphical notation shows an allocation edge between perform edges, owned by an allocation edge between parts.
It is for sure confusing, and not sure if the textual notation that says

 allocate part1.action1 to part2.action2; 

is correct, provided that action1 and action2 are performed but not owned actions.
Even if technically correct, it would be better to present a clearer and simpler example of composite allocations.

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.

1. The GBNF production for a transition is wrong, it does not account for nodes which are not states (e.g. control nodes)

2. The production for states actions compartment is incorrect, the compartment name is currently named "states" while it should be named "state actions".

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 the graphical BNF should reuse the textual syntax productions DefinitionDeclaration and UsageDeclaration.

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.

There are 94 uses of the word 'however' in the specification, usually starting a sentence. In many cases, the word injects unnecessary text that further confuses and obfuscates the intent. In most cases, what follows is not an exception, rather just another option of the language. In many cases the word can be replaced with ‘if’ or ‘when’ but I also found many cases where a rewrite is necessary.

Here are the first 45ish specific examples and rewrites. I stopped at page 119 as there is enough evidence to show simple rewriting of the offending test can greatly improved the text. I have also added comments to point to the issue and any further wordsmithing that seems to be required.
This seems like a minor or even a style issue, ‘however’ the point of this issue is that the use of the word muddles the descriptive intent of the text when it should be precise as possible.

2. conformance:
Original:
However, a tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.
Replacement:
A tool demonstrating Concrete Syntax Conformance need not represent a model internally in exactly the form modeled for the abstract syntax in this specification.

6.2 Document Organization
Original:
However, this clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Replacement:
This clause does not cover details of the Kernel metamodel, which are included by normative reference to the KerML specification [KerML].
Comment:
Optionally delete the sentence as it is already assumed that KerML is where the reader finds the details of the details.

6.3 Acknowlegements
Original:
However, work on the specification was also supported by over 200 people in over 80 organizations that participated in the SysML v2 Submission Team (SST), by contributing use cases, providing critical review and comment, and validating the language design.
Replacement:
Over 200 people from over 80 organizations participated in the SysML v2 Submission Team (SST), contributing to the specifics and providing reviews and comments.

7.2.1 Elements and Relationships Overview
Original:
However, in some cases, additional shapes may be attached to relationship lines in order to present additional information.
Replacement:
Additional shapes may be attached to relationship lines in order to present additional information.

7.2.2 Elements
Original:
Various specific kinds of model elements in SysML are described in subsequent subclauses. However, there are certain concepts that apply to all model elements.
eplacement:
Key model elements in SysML are described in subsequent subclauses. Some of the concepts apply to all model elements.
comments: The opening statement like this are without value to the spec.

Original:
The SysML notation does not have any provision for specifying element or alias IDs, since these are expected to be managed by the underlying modeling tooling. Instead, an element can be given a name and/or a short name, and it can also have any number of alias names relative to one or more namespaces (see 7.5).
Replacement:
The SysML notation does not have any provision for specifying element or alias IDs because these are expected to be managed by the underlying modeling tooling. Instead of using an ID, an element has a given name and/or a short name that can also have any number of alias names relative to one or more namespaces (see 7.5).

Original:
However, unless at least one of these is given, it is not possible to reference the element using the textual notation (though it is still possible to show it in relationships on graphical diagrams).
Replacement:
It is not possible to reference the element using the textual notation unless a name or short name is given, though it is still possible to show it in relationships on graphical diagrams.

Original:
However, a reserved word may not be used as a name, even though it has the form of a basic name (see 8.2.2.1.2 for the list of the reserved words in SysML).
Replacement:
A reserved word may not be used as a name (see 8.2.2.1.2 for the list of the reserved words in SysML).

Original:
However, these characters may be included as part of the name itself through use of an escape sequence.
Replacement:
Non-printable characters may be included as part of the name itself through use of an escape sequence.

7.4.2 Comments and Documentation
Original:
However, marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Replacement:
Marked up "rich text" for a comment is stored in the comment body in plain text including all mark up text, with all line terminators and white space included as entered, other than what is removed according to the rules referenced above.
Original:
However, for any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented
Replacement:
For any other language than "sysml", the SysML specification does not define how the body text is to be semantically interpreted as part of the model being represented

7.5.4 Import Filtering
Original:
comments. Namespaces other than packages cannot have filter conditions (except for their special use in view definitions and usages – see 7.25). However, any kind of namespaces may have filtered imports.
Replacement:
Namespaces other than packages cannot have filter conditions, except for their special use in view definitions and usages – see 7.25. All kinds of namespaces may have filtered imports.
comments: It is strange that this is a note as these are very specific semantics rather than an aside as would be described in a note.

7.6.1 Definition and Usage Overview
Original:
However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
Replacement:
Alternatively the Truck could redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel.
comments: The paragraphs are rather confusing without a textual language or graphical examples. At least you could refer to an example in the annex. It is also odd to get into alternatives without an example of the alternative.
Original:
However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
Replacement:
If Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.

7.6.3 Usages
Original:
However, a tighter default of [1..1] is implicitly declared for the usage if all of the following conditions hold
Replacement:
A tighter default of [1..1] is implicitly declared for the usage if all of the following conditions are true:
Comment: Is there a reference to where this is described in the standard?

7.6.4 Reference Usages
Original:
However, a reference usage is always, by definition, referential. A reference usage is otherwise declared like any other usage, as given above.
Replacement:
Reference usages are always referential. A reference usage is declared like any other usage, as given above.
Comment:
Once the ‘however’ was removed, the changes to the following sentence is also required to improve the explanation of the concept.

7.6.5 Effective Names
Original:
However, if neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Replacement:
When neither a name or a short name are given in the declaration of a usage with an owned redefinition, then its effective name and short name are implicitly determined by the name and short name of the redefining usage of its first owned redefinition (which may itself be an implicit name, if the redefined usage is itself a redefining usage).
Comment:
The use of ‘however’ muddled the original explanation. Imagine Java or some other computer language with ‘however’ as a key word.

7.6.6 Feature Chains
Original:
However, their use is particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)
Replacement:
Feature chains are particularly important when specifying the related features of a connection usage that are more deeply nested than the connection usage itself (see 7.13). (See also [KerML, 7.3.4.6].)

7.6.8 Implicit Specialization
Comment:
This may be a good use of however, but look at it anyway and see if it can be avoided,

7.7.1 Attributes Overview
Original:
However, the owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). In this case, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Replacement:
The owner of an attribute usage may be an occurrence definition or usage (or a specialized kind of occurrence, such as an item, part or action). When the attribute owner is a usage is an occurrence definition or usage, the value of the attribute usage may vary over the lifetime of its owning occurrence, in the sense that it can have different values at different points in time, reflecting the changing condition of the occurrence over time.
Comment:
This is still confusing. It again screams out for a textual/graphical language example.

7.8.1 Enumerations Overview
Original:
However, if the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Replacement:
If the enumeration definition specializes an attribute definition with nested usages, then those nested usages will be inherited by the enumeration definition, and they may be bound to specific values within each enumerated value of the enumeration definition.
Original:
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.
Replacement:
The reason for this constraint is that enumerated values defined in an enumeration definition would add to the set of enumerated values, which is inconsistent with the semantics of specialization.
Comment:
This is a definite improvement over the original text, which is very confusing. It is very strange that given you are creating a new language to get around issues with UML you have not fixed this glaring issue of the inability to specialize enumerations.

7.8.2 Enumeration Definitions and Usages
Original:
However, an enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Replacement:
An enumeration definition must not subclassify another enumeration definition. An enumeration usage is declared as described in 7.6.3, using the kind keyword enum.
Comment:
This paragraph seems like a repeat of the previous change request. Suggest choosing one and deleting the other to reduce confusion and need to maintain both statements.

7.9.1 Occurrences Overview
Original:
However, if a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Replacement:
If a composite suboccurrence is removed from its containing occurrence before the end of the lifetime of the containing occurrence, then the former suboccurrence can continue to exist.
Original:
However, if the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)
Replacement:
If the wheel is removed before the car is destroyed, then the wheel can continue to exist even after the car is destroyed. (See also 7.6 on referential and composite usages.)

Original:
However, it could also be realized as the start and end of an explicitly modeled flow connection (see 7.13 on flow connections and messages).
Replacement:
These events can also be realized as a modeled flow connection (see 7.13 on flow connections and messages).
Comment:
This is another statement that becomes more muddled when treating it as an exception when in fact this is not an exeption, but just realkized by another possible construct.

7.9.3 Time Slices and Snapshots
Original:
However, if such an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.
Replacement:
If an occurrence usage has no explicitly declared definition, but is declared in the body of an occurrence definition, then it is considered to implicitly represent a portion of instances of the containing occurrence definition.

7.10.1 Items Overview
Original:
However, once the engine assembly is completed, the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. But later it may be removed from the car and again be considered only an inactive item in a junkyard.
Replacement:
Once the engine assembly is completed (e.g. the engine has completed manufacturing and exists as a whole), the engine can be considered to be a part that may be installed into a car, where it is expected to perform the action providing power to propel the car. Later in time, the engine may be removed from the car and again be considered only an inactive item in a junkyard.
Comment:
This is a weird example. There are many parts to an engine that are added and removed. For example, spark plugs. A spark plug could be a better example as these are assembled of pieces that are not individually replaceable and junked as a whole.

7.13.1 Connections Overview
Original:
However, the values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Replacement:
The values of connection ends (i.e., the things that are actually connected) do not change over time (though they can potentially be occurrences that themselves have features whose values change over time).
Original:
However, a message does not specify how the payload is to be obtained from the source or delivered to the target.
Replacement:
A message does not specify how the payload is to be obtained from the source or delivered to the target.
Comment:
So how do we specify how it obtained? This needs further clarification.

7.13.2 Connection Definitions and Usages
Original:
However, if it declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.
Replacement:
If a connection definition declares any owned end features, then each of these must redefine an end feature of the general connection definition, in order, up to the number of end features of the general connection definition.

7.13.4 Feature Values
Original:
However, for a default, bound feature value, the symbol = may be elided.
Replacement:
Optionally. a default, bound feature value, the symbol = may be elided (as shown in the default ‘mass’ in the following example).
Comment:
This a capricious and confusing option. Please choose one and delete the other. This adds a complication to the reading of the language that is unnecessary.

7.13.6 Flow Connection Usages and Messages
Original:
A streaming flow is declared similarly to a message, but with the kind keyword flow. However, instead of identifying the source and target features of the flow, such a flow declaration must identify (after the keyword from) the output feature of the source from which the flow receives its payload and (after the keyword to) the input feature of the target to which the flow delivers the payload.
Replacement:
A streaming flow has the kind keyword flow and must identify, after the keyword from, the output feature of the source from which the flow receives its payload and, after the keyword to, the input feature of the target to which the flow delivers the payload.
Comment:
The use of ‘however’ has created language of no value. The streaming flow is totally different than a message in its form. The rewrite hopefully fixes the first mistake, however the sentence is still rather obtuse and still needs some wordsmithing.

7.14.2 Interface Definitions and Usages
Original:
However, if the declaration part of an interface usage is empty, then the interface keyword is still included, but the connect keyword may be omitted.
Replacement:
If the declaration part of an interface usage is empty, then the connect keyword may be omitted.

7.16.1 Actions Overview
Original:
However, if the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the perform action usage is an occurrence, then the referenced action performance must be carried out entirely within the lifetime of the performing occurrence.

Original:
However, a succession between action usages may, additionally, have a guard condition, represented as a Boolean expression (see 7.18).
Replacement:
A succession between action usages may have an additional guard condition, represented as a Boolean expression (see 7.18).

7.16.5 Conditional Successions
Original:
However, the target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.
Replacement:
The target of a conditional succession must be specified as a qualified name or feature chain and cannot be a full action usage declaration, even when the shorthand notation is used.

7.17.1 States Overview
Original:
However, if the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.
Replacement:
If the owner of the exhibit state usage is an occurrence, then the referenced state performance must be carried out entirely within the lifetime of the performing occurrence.

7.17.2 State Definitions and Usages
Original:
However, if the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. (However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
If the keyword parallel is added to a state definition or usage, just before the body part, then the containing state definition or usage becomes a parallel state, and its contained state usages can be performed in parallel. In this case, no transitions are allowed between concurrent states; see 7.17.3.

Original:
(However, no transitions are allowed between concurrent states; see 7.17.3.)
Replacement:
No transitions are allowed between concurrent states; see 7.17.3.

7.19.1 Constraints Overview
Original:
In general, a constraint may be satisfied sometimes and violated other times. However, an assert constraint usage asserts that the result of a given constraint must be always true at all times.
Replacement:
When an assert constraint usage asserts exists, the result of that constraint must be always true at all times. This is compared to a simple constraint may be satisfied sometimes and violated other times.
Comment:
This another example of the ‘however’ causing a confusion in the semantics. The spec should say what is true before saying what is true is an exception. In this case, there is no exception, just a differing kind of constraint than one already discussed.

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

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

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

An object flow with a guard is mapped to a conditional succession and a succession flow. Conditional succession targets the succession flow. Both have the decision node as the source element. However, only one succession outgoing decision node can be taken.

Change the mapping to:

first sourceNode if guardCondition.result then objectFlow {
  constraint guardCondition {
    bind result = guardCondition.result;
    calc guardCondition {
      language "English"
      /*
       * guard says ok
       */
    }
}
flow objectFlow from sourceNode to targetNode;
first source then target;

The source and target of the flow succession are parameters (the target elements of the corresponding SysML v1 ObjectNodes). The source and target of the succession are the owner of the object nodes. Exceptional cases are control nodes.

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

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

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

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

An ObjectFlow is mapped to a succession flow including the specification of the payload: "...of <type>".

The type of the flowing objects cannot be precisely determined (for example, if the source of the object flow is a merge node). Additionally, the ObjectFlow in SysML v1 also has no relationship to the type of the flowing objects.

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

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

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

A ConnectionPointReference is mapped to a StateUsage. In addition, the state usage shoud redefine the corresponding pseudostate.

In subclause 7.26.1, Table 25, two typos appear in examples "Metadata" and "Metadata Compartment". In the graphical notation for both, AttributeDef1 should be replaced with MetadataDef1, in line with the textual notation.

The mapping class RICOAOutputPin_Mapping has no general mappings but should have Pin_Mapping

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.

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

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

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

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.

The chapter 7.7.5.3.7 Trigger_Mapping is empty.

The specification incorrectly mentions that CallEvent is not part of the SysML v1.7 specification, which is why no transformation is offered for either CallEvent or AcceptCallAction.

According to Table 4.2 about the included UML metaclasses in the SysML v1.7 specification, CallEvent and AcceptCallAction are part of SysML v1.7. A mapping must be specified accordingly.

Terminate node is about to be introduced to the language, need to assure it is covered by the graphical bnf

name compartment productions for send and accept actions are not reusing the textual productions for usage declarations and misaligned with the rest of the graphical BNF

A use case can have many subjects. The transformation considers only one. If there are more subjects specified, it only takes the first one in the list.

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

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

Allow flows to connect ControlNodes because, currently, this limitation makes it impossible to pass payloads from one ActionUsage to another ActionUsage if a DecisionNode is in between.
This issue is a showstopper for the UAF v2 development.

Currently two conventions are used for graphical action names e.g. send action vs. assign, so issue is whether the action postfix is used or not. Note that the textual notation does not use the postfix action. Regardless, this needs to be aligned along the GBNF and representative notation tables.

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.

There is a bunch of mapping defined in the "GenericMappings::Common" package. However, they are not used very much in by other mappings while multiple more specific versions of them have been created without a good rationale. Defining reusable mappings is a good idea and could greatly simplify the specification of the transformation by reducing the number of classes it contains... Assuming they are actually used!

I do think it deserves a global review and optimization.

Note that some of those "common" mappings shall be fixed with regard to either their source type, the body condition of some of their rules or both.

In case the client of the client of the Satisfy relationship is a block, a ReferenceUsage will have to be generated. The type of that ReferenceUsage shall be the Definition corresponding to that block.

It is necessary to create a reference usage if and only if the client of the Satisfy relationship is a block. Instead, the current version of the Satisfy_Mapping create it if and only if the client is a property

Clause 7.7.3.3.17 (CommonActivityEdgeSuccessionAsUsage_Mapping), Description says

The mapping class provides a common mapping of a UML4SysML::ActivityEdge to a SysMLv2 SucessionAsUsage.

Clause 7.7.3.3.35 (ObjectFlow_Mapping), Description, says

A UML4SysML::ObjectFlowFlow without a guard condition is mapped to a SysMLv2SuccessionFlowConnectionUsage.

This seems to say all ActivityEdges, including ObjectFlows are mapped to v2 Successions, is that right? This prevents mapping of object flows from/to streaming parameters, which enable actions to provide output and take input while they are executing, with object flows between the respective pins potentially defining guards to filter which items move across which object flows, per UML 2.5, Clause 15.2.3.3 (Activity Edges), second paragraph.

The above isn't mentioned, AFAICT, in the various "not mapped" tables, and the term "stream" doesn't appear anywhere in the Transformation specification.

SatisfyRequirementUsage subsets Requirements::notSatisfiedRequirementChecks or Requirements::satisfiedRequirementChecks in pilot implementation.

checkSatisfyRequirementUsageSpecialization constraint should be defined in the specification.

In the Systems Library model Parts, the base part definition Part is declared to have the features ownedPorts, ownedActions and ownedStates. These features are described in 8.4.7 Parts Semantics, noting that the are covered further in 8.4.8 Ports Semantics, 8.4.12 Actions Semantics and 8.4.13 States Semantics, respectively. More specifically, 8.4.8.2 Port Usages, 8.4.12.2 Action Usages and 8.4.13.2 State Usages state that the semantic constraints checkPortUsageOwnedPortSpecialization, checkActionUsageOwnedActionSpecialization and checkStateUsageOwnedStateSpecialization determine the required specialization of the relevant Part features. However, of these, checkActionUsageOwnedActionSpecialization is defined in the abstract syntax, but the other two are not.

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

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

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

In subclause 7.20.1, Table 19, example "Requirement" the compartment labels "require constraints" and "assume constraints" and their content are misleading and inconsistent. Besides pure "require ConstraintUsage" statements a "require constraints" compartment may also contain "require RequirementUsage" statements. A "require RequirementUsage" has the same semantics as a RequirementUsage contained (isComposite==true) by a containing RequirementUsage (see explanation in subclause 7.20.2). Therefore a better compartment name is possibly "requires".

The same problem applies to other compartment names for reference usages. The full list of compartments to be made consistent is:
asserts, assumes, assert, exhibits, performs, requires, satisfies, verifies, include use cases. (Note: frames and frame concerns not included)

In clause 7.16.1, Table 14, example "Action with Parameters", the name "param2 : ItemDef2" of the out parameter on the righthand side should be placed outside the action1 rectangle.

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

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

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

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

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.

The Analysis Domain Library model TradeStudies includes the following definition:

	requirement def MinimizeObjective :> TradeStudyObjective {
		doc
		/*
		 * A MinimizeObjective is a TradeStudyObjective that requires that the 
		 * selectedAlternative have the minimum ObjectiveFunction value of all the
		 * given alternatives.
		 */
		 
		subject :>> selectedAlternative;
		in ref :>> alternatives;
		in calc :>>fn;
	
		out attribute :>> best = alternatives->minimize {
			doc
			/*
			 * For a MinimizeObjective, the best value is the minimum one.
			 */
		
			in x; fn(x)
		};
	}

(and there is a similar definition for MaximizeObjective that uses maximize instead of minimize). Unfortunately, in the definition minimize in the Kernel Function Library model ControlFunctions, the functional argument to minimized is named fn, and, in the expression fn(x), the name fn gets bound to this parameter, instead of to MinimizeObjective::fn. This means that an evaluation of the invocation of minimize as given will result in an infinite recursion (and similarly for the call to maximize in MaximizeObjective).

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:

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.

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

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

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

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.