According to the Graphical BNF, the notation for a nested reference usage is now a white diamond in the upper-right hand corner of the usage shape (or optionally a black diamond for a non-reference usage, which is the default). In the Graphical BNF productions this is represented by rd = (reference-diamond)? as defined in clause 8.2.3.6. This is a change from the previous dashed-outline shape as also used in SysML v1.

There are arguments pro and con for which notation might be the more usable, including the affinity of the white diamond with a feature membership, but also continuity with SysML v1 and its visibility of the distinction around the whole shape.

The new notation was proposed primarily to avoid the practical difficulties providing dashed-outline versions of every usage shape in the BNF, but the notation should be properly decided on its own merits, not to make things easier for the BNF. An informal comment could be provided in the BNF simply stating that a dashed-outline version is available for each shape according to whether it is a reference usage. An additional alternative is to use dotted-outline, with the advantage that it more closely follows non-right-angled shapes, such as rounded rectangles used for usages.

After discussion the Graphical Specification WG recommends to replace the upper-right-hand corner reference-diamond notation with a dotted-outline for reference usage, and stay with a solid-outline for composite usage.

Current Graphical BNF needs to have a production for a keyword notation with and without the base class enabled for all name compartments.

Graphical BNF should allow for graphical relationships such as causation connection from a state (i.e. cause) to a transition (i.e. effect) or from one transition (i.e., cause) to another transition (i.e., effect). These should be supported in the general view.

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

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.

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

Some multiple specializations in the libraries might be intended to be intersections, including feature specializations. For example, from SYSML2-490, under Actions::Actions

action sendSubactions: SendAction[0..*] :> subactions, sendActions {
  doc /* * The subactions of this Action that are SendActions. */ }

action acceptSubactions: AcceptAction[0..*] :> subactions, acceptActions {
  doc /* * The subactions of this Action that are AcceptActions. */ }

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.

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.

In 7.16.9 Assignment Action Usages, at the beginning of the second text paragraph, it states

If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage.

However, there is no semantic constraint to enforce this (see 8.3.16.5).

Currently binding connector graphical production overly constraining the possible permutations to two specific cases. it needs to be generalized to bind usage-nodes in general where they have to be of consistent types.

The approved resolution to KERML-195 adds a note to the ItemFlowFeature production in the KerML concrete syntax grammar on properly setting the direction of the synthesized feature. A similar note should be added to the FlowFeature production in subclause 8.2.2.13.4 of the SysML textual notation grammar.

The approved resolution to SYSML2-28 includes adding the constraint validateTriggerInvocationExpressionAfterArgument, which requires:

If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.

However, in a typical relative time trigger such as, e.g., after 10[SI::s], the result of the expression 10[SI::s] is not a DurationValue. Rather it is a ScalarQuantityValue whose mRef is the DurationUnit SI::s. Therefore, this example time trigger violates validateTriggerInvocationExpressionAfterArgument as specified in the resolution to SYSML2-28.

The approved resolution to KERML-20 adds the validation constraint validateFeatureValueOverriding that "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues." There are a number of cases of models in the Domain Libraries that violate this constraint.

1. Analysis Domain Library – TradeStudy.sysml, argument in the invocation of tradeStudyObjective (see also SYSML2-491).
2. Geometry Domain Library
   • SpatialIttems::SpatialItem::componentItems::coordinateFrame::transformation::target is given a default, but is already bound
   • ShapeItems::Circle::radius is bound, but needs to be overridable
3. Quantities and Units Domain Library
   • Quantities::TensorQuantityValue::order redefines rank and is bound to mRef.order, but rank is already bound for an Array.
   • ISQSpaceTime::CartesianSpatial3dCoordinateFrame::mRef is bound, but needs to be overridable.
   • Several cases in ISQ models of dimensions = 3 even though, for a quantity value, dimensions is already bound to mRef.dimensions.
   • Time::Iso8601DateTimeStructure::mRef is bound to UTC, but it is already bound to UTC for a UTCInstanceValue.
   • VectorCalculations::transform::targetVector::dimensions is bound, but it is already bound for a VectorQuantityValue.

The approved resolution to KERML-20 adds the validation constraint validateFeatureValueOverriding that "All Features directly or indirectly redefined by the featureWithValue of a FeatureValue must have only default FeatureValues." This constraint causes problems for two models in the Systems Model Library. These library models do not actually violate the constraint, but using the models as intended my violate the constraint.

1. In the action definition Actions::AcceptAction, the inout paramater payload is redefined with a feature value binding it to aState.aTransition.aPayload. However, when an accept action is parsed with a change or time trigger, the payload is implicitly bound to the generated change or time signal, and this violates the validateFeatureValueOverriding constraint.
2. In the analysis case definition AnalysisCases::AnalysisCase:
   • The subject of the objective of AnalysisCase is bound to the result parameter of the AnalysisCase. However, when specifying an analysis case, it is sometimes convenient to compute a check of the case objective by evaluating it on a given subject value. However, the binding of such an subject argument then violates the validateFeatureValueOverring constraint.
   • The result parameter is bound to the result of the AnalysisCase::resultEvaluation calculation feature. However, when defining an analysis case in a user model, it is natural to bind the computation of the result of the case to the result parameter as a feature value. But this then violates the validateFeatureValueOverriding constraint.

The end features of MessageConnection, FlowConnection and SuccessionFlowConnection in the standard library package Connections are typed as Occurrences, but they are currently syntactically reference usages, not occurrence usages. However, the abstract syntax for EventOccurrenceUsage requires that its referenced eventOccurrence must actually be an OccurrenceUsage. This means that the source and target ends of, e.g., a message, if inherited from MessageConnection and not redefined, cannot be referenced by EventOccurrenceUsages, which prevents an intended use in "sequence diagram" modeling.

In 8.3.17.6 StateUsage, the description of checkStateUsageSpecialization is

A StateUsage must directly or indirectly specialize the StateUsage States::stateActions from the Systems Model Library.

but the OCL is

specializesFromLibrary('States::StateAction')

which requires specialization of StateAction, not stateActions.

The following statements are made in Clause 7 (Language Description) of the SysML v2 specification:

• Subclause 7.6.3 (Usages): "Note also that a directed usage is always referential, whether or not the keyword ref is also given explicitly in its declaration."
• Subclause 7.13.2 (Connection Definitions and Usages): "The end features of a connection definition or usage are always considered referential (non-composite), whether or not their declaration explicitly includes the ref keyword."

However, there are currently no constraints on the Usage class in the abstract syntax to enforce these rules (see 8.3.6.4).

In addition, a usage that is not explicitly declared as a feature of a type is, by default, considered to be a feature of the base type Anything. However, since Anything is not a kind of Occurrence, its features cannot be composite. Therefore, such usages should be always referential.

The following validation constraints are implied by textual descriptions in the specification, but are missing in the abstract syntax. They should be added, along with appropriate OCL.

8.3.16.5 AssignmentActionUsage

validateAssignmentActionUsageArguments – An AssignmentActionUsage must have two argument Expressions.

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

8.3.16.9 ForLoopActionUsage

validateForLoopActionUsageLoopVariable – The first ownedFeature of a ForLoopActionUsage must be a ReferenceUsage.

validateForLoopActionUsageParameters – A ForLoopActionUsage must have two owned input parameters.

8.3.16.10 IfActionUsage

validateIfActionUsageParameters – An IfActionUsage must have at least two owned input parameters.

8.3.16.16 TriggerInvocationExpression

validateTriggerInvocationExpressionAfterArgument – If a TriggerInvocationExpression has kind = after, then it must have an argument Expression with a result that conforms to the type ISQ::DurationValue.

validateTriggerInvocationExpressionAtArgument – If a TriggerInvocationExpression has kind = at, then it must have an argument Expression with a result that conforms to the type Time::TimeInstantValue.

validateTriggerInvocationExpressionWhenArgument – If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.

8.3.16.18 WhileLoopActionUsage

validateWhileLoopActionUsageParameters – A WhileLoopActionUsage must have at least two owned input parameters.

8.3.17.2 ExhibitStateUsage

validateExhibitStateUsageReference – If an ExhibitStateUsage has an ownedReferenceSubsetting, then its referencedFeature must be a StateUsage.

8.3.19.2 AssertConstraintUsage

validateAssertConstraintUsageReference – If an AssertConstraintUsage has an ownedReferenceSubsetting, then its referencedFeature must be a ConstraintUsage.

8.3.20.10 SatisfyRequirementUsage

validateSatisfyRequirementUsageReference – If a SatisfyRequirementUsage has an ownedReferenceSubsetting, then its referencedFeature must be a RequirementUsage.

8.3.24.2 IncludeUseCaseUsage

validateIncludeUseCaseUsageReference – If an IncludeUseCaseUsage has an ownedReferenceSubsetting, then its referencedFeature must be a UseCaseUsage.

GCG agreed on non-ambigous notations for various types of flows and flows embedded on connections.
It needs to be corrected in the BNF in the relevant sections

In the SysML Specification, 8.3.16.5 AssignmentActionUsage, the constraint deriveAssignmentActionUsageReferent states that "The referent of an AssignmentActionUsage is the first Feature that is the memberElement of a ownedMembership that is not an OwningMembership." However, according to the BNF in 8.2.2.16.5 Assignment Action Usages, the intended referent of an assignment is parsed as a FeatureChainMember, and, for an actual chain of more than one Feature, the chaining Feature is owned by the AssignmentActionUsage via OwningMembership. Therefore, it will not be identified as the referent of the assignment according to the current derivation.

The approved resolution to SYSML2-28 included adding the constraint validateTriggerInvocationExpressionWhenArgument, which requires:

If a TriggerInvocationExpression has kind = when, then it must have an argument Expression with a result that conforms to the type ScalarValues::Boolean.

However, the argument to a when trigger is not supposed to be an Expression with a Boolean result. Rather, it is an Expression whose result is the Evaluation of an Expression whose result is Boolean. That is, a trigger like when x > 0 is parsed as TriggerWhen({x > 0}), not as TriggerWhen(x > 0). So all properly parsed when triggers will violate validateTriggerInvocationExpressionWhenArgument as specified in the resolution to SYSML2-28.

In the Systems Model Library, the features Actions::Action::acceptSubactions and Actions::Action::sendSubactions should subset Actions::acceptActions and Actions::sendActions, respectively.

In the SysML Specification, 7.6.7 Variations and Usages states “A variation is always abstract, so the abstract keyword is not used on a variation.” And, indeed, the textual notation BNF in 8.2.2.6.1 Definitions and 8.2.2.6.2 Usages allows either the abstract or variation keyword to be applied to a definition or usage declaration, but not both. However, there are no constraints in the abstract syntax subclauses 8.3.6.2 Definition or 8.3.6.4 Usage to enforce this.

Subclause 9.8.8 on the Time package in the Quantities and Units Domain Library does not include documentation of defaultClock, which is in the normative library model.

In 9.4.3.2.5 Sample (in the Sampled Function model in the Analysis Domain LIbrary), the feature calculation has type CalculationUsage. However, in the actual library model, calculation is a CalculationUsage, which means it should have the base library definition Calculation as its type, not the abstract syntax element CalculationUsage

The connection definition Causation in the CausationConnections library package has two ends that redefine the non-end features causes and effects from Multicausation.

However, in the normative CausationConnections.sysml file from the Cause and Effect Domain Library project, these ends are declared to only subset the source and target ends inherited from BinaryConnection. As a result, the connection definition ends up having four ends rather than two, which is incorrect. Its ends need to redefine source and target, rather than just subsetting them.

In subclause 9.5.2.2.1 of the specification document, on the other hand, Causation is not shown as specializing BinaryConnection at all, and the ends are shown as only redefining the non-end features from Multicausation.

In the SysML specification document, in 9.2.9.2.4 Action, the feature decisionActions is stated as subseting transitions. However, in the normative Actions.sysml library model, Action::decisionTransitions currently subsets transitionActions. It should instad subset Action::transitions, as given in the specification.

Currently, in the Geometry Domain Library model SpatialItems, the calculation definitions PositionOf and CurrentPositionOf return vectors defined by the generic definition VectorQuantityValue. These should be specialized more narrowly to ISQ::Position3dVector.

In the Views::View model as submitted, viewpointSatisfactions was accidentally declared as redefining viewpointChecks. This should be changed to subsetting, so that there can be (non-composite) viewpoint references within a view that subset viewpointChecks but not viewpointSatisfactions.

Further, because View is a kind of Part, viewpointSatisfactions also has an implied specialization of Item::checkedConstraints. It would be better if this was explicit, to make it clear that any declaration in a View subsetting viewpointSatisfactions automatically satisfies the requirement to subset checkedConstraints, so that this does not require an additional implied specialization.

The Kernel Standard Library model for Transfers includes the following features, documented in subclauses of 9.2.7.2:

• 9.2.7.2.4 flowTransfers
• 9.2.7.2.5 flowTransfersBefore
• 9.2.7.2.7 messageTransfers
• 9.2.7.2.11 transfers
• 9.2.7.2.12 transfersBefore

In all these cases, the "Element" kind is documented simply as "Feature". However, in the normative Transfers.kerml file, all of these features are actually declared as steps.

The enumeration definitions VerdictKind and VerificationMethodKind, which are in the normative Systems Model Library package VerificationCases, are missing from Systems Model Library subclause 9.2.16 Verification Cases in the SysML Specification.

1. Subclause 9.8.1 paragraph 2 sentence 2, contains a typo: "The library also provides enables the specification ..." should read "The library also enables the specification ...", i.e. delete "provides".
2. Subclause 9.8.2.1 example 1 under Free versus Bound Quantities and Vector Spaces, contains a typo: "Displacement vector (free) and the position vector (bound), ..." should read "Displacement vector (free) and position vector (bound), ...", i.e. delete "the".

The issue SYSML2-241 is merged into SYSML2-240. Both issues are approved. The resolution of SYSML2-240 does not consider the issue SYSML2-241.

TestCaseVerifyRequirementUsage_Mapping ::ownedRelationships() uses the mapping classes CaseSubjectMembership_Mapping, which do not exist.

It existed in a previous version but was removed without updating TestCaseVerifyRequirementUsage_Mapping .

TestCaseVerifyRequirementUsage_Mapping.ownedRelationship() contains the following code:

CaseSubjectMembership_Mapping.getMapped(from.client),

Since from.client is a collection the code specified cannot work. This makes MIWIG test case #37 failing

In the Analysis Domain Library model TradeStudies::TradeStudy, the requirement definitions MinimizeObjective and MaximizeObjective explicitly redefine the parameter best from the TradeStudyObjective definition they specialize, but do not declare any other parameters. However, this violates the checkFeatureParameterRedefinition constraint, which requires that parameters be redefined in order. And, if the implied redefinition is added to the actual first parameter selectedAlternative, then this also violates the validateRedefinitionDirectionConformance constraint (add by the approved resolution to KERML-20), because best is an out parameter, while selectedAlternative is an in parameter.

In 8.3.20.9 RequirementUsage, the checkRequirementUsageObjectiveRedefinition constraint requires that "A RequirementUsage whose owningFeatureMembership is a ObjectiveMembership must redefine the objectiveRequirement of each CaseDefinition or CaseUsage that is specialized by the owningType of the RequirementUsage." However, the objectiveRequirement property of a CaseDefinition (see 8.3.21.2) or a CaseUsage (see 8.3.21.3) is derived to be only the owned objective of the case. This means that, if a case declares an owned objective, but specializes a case with an inherited objective, then checkRequirementUsageObjectiveRedefinition will actually be satisfiable.

Sections 7.7.4 - 7.7.14 and Section 7.8.5 should contain the introductory sentence:

This chapter lists all mapping specifications of <namespace> model elements.

For example, as in Section 7.7.3:

This chapter lists all mapping specifications of UML4SysML::Activities model elements.

The sentence "The justifications for the elements without mapping are given in view link does not exist" in the State Machines overview sentence does not make sense and should be removed.

The sentence "The justifications for the elements without mapping are given in view link does not exist" in the Classification overview sentence does not make sense and should be removed.

Time and change triggers for an accept action are supposed to be parsed as a TriggerInvocationExpression with a single argument: for a time trigger, the argument is a duration or time instant, while for a change trigger it is a boolean expression. However, the textual notation BNF for TriggerExpression in 8.2.2.16.4 is not properly parsing the textual notation as an invocation with arguments. As a result, the intended argument expression for the TriggerInocationExpression will not actually be recognized as an argument of the invocation.

In the textual notation grammar, RequirementConstraintUsage produces a ConstraintUsage, but the first alternative in the production allows the ConstraintUsage to have a RequirementBody. The RequirementBody production allows kinds of declarations (such as subjects and actors) that are not valid in the body of a ConstraintUsage (because of validation constraints such as validateSubjectMembershipOwningType, validateActorMembershipOwningType, etc.). There is no point in syntactically allowing owned members that are then invalid, so the first alternative in RequirementConstraintUsage should have a CalculationBody (like the second alternative) rather than a RequirementBody.

The production for <SourceSuccessionMember > has "+" and it should be "+="

SourceSuccessionMember : FeatureMembership =
'then' ownedRelatedElement + SourceSuccession

The production for <SourceEndMember> has "+" and it should be "+="

SourceEndMember : EndFeatureMembership =
ownedRelatedElement + SourceEnd

The option for <PrefixComment> has been deprecated, but is still an option for AnnotatingElement. Remove PrefixComment.

AnnotatingElement =
  Comment
| PrefixComment
| Documentation
| TextualRepresentation
| MetadataUsage

Prior error report on this production can be replaced with this error report.

The issue is with the production:

FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping

The correct conjugate nonterminal should be <ConjugatedPortTyping>

In the production:

FeatureTyping = OwnedFeatureTyping | ConjugatePortTyping

There is no corresponding production for the non-terminal <ConjugatePortTyping>.
<ConjugatedPortDefinitionMember> or <ConjugatedPortDefinition> may be correct for <FeatureTyping>.

The current specification:

SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement + SourceSuccession

SourceSuccession : SuccessionAsUsage =
    ownedRelationship += SourceEndMember

    SourceEndMember : EndFeatureMembership =
ownedRelatedElement + SourceEnd

is incorrect. It should be:

SourceSuccessionMember : FeatureMembership =
    'then' ownedRelatedElement += SourceSuccession

SourceSuccession : SuccessionAsUsage =
    ownedRelationship += SourceEndMember

    SourceEndMember : EndFeatureMembership =
ownedRelatedElement += SourceEnd

The approved resolution for issue SYSML2-180 uses the mapping class GenericToItemUsage_Mapping which does not exist. It seems that it was overseen to add the creation of the mapping class to the revised text of the resolution.

The generic mapping class GenericToItemDefinition_Mapping specializes GenericToDefinition_Mapping. However, it should specialize GenericToOccurrenceDefinition_Mapping which is a subclass of GenericToDefinition_Mapping as well as ItemDefinition specializes OccurrenceDefinition.

In example "Interface as Node" remove arrow heads from the nested connections, and move arrow head between pa and pb to end of line, add message of item1:Item1 from pa to pb to the interface2 usage in the textual notation. Also add open curly bracket directly after interface2, and closing curly bracket after the ellipsis.

In example "Flow as Node" check whether flow from source :> action1.item1 should be reference subsetting? Add keyword from to the nested flows.

In example "Binding Connection" «ref part» part4R should use the graphical notation as specified in the graphical BNF in subclause 8.2.3.11.

In example "Variants Compartment" textual notation should include part def PartDef1, and item def ItemDef1, and also part1 : PartDef1 and item1 : ItemDef1.

Example "Subsetting" is missing specification of the perform action action1 : Action1 that is shown as inherited in the graphical notation. Add part def Part1 in textual notation from preceding example "Usage Definition".

ElementMain_Mapping::ownedRelationship deals with owned comments and tries to create an ownership relationship thanks to ElementOwnership_Mapping.
Instead, this is an Annotation relationship that shall be used here. We can get it thanks to the CommentAnnotation_Mapping.

However, CommentAnnotation_Mapping misses the computation of ownedRelatedElement that is left to its default value, meaning that the ownership of a comment is never set.

The transformation does not specify mapping rules for SysMLv1::~InterfaceBlock.

In 7.13.1 Connections Overview, Table 15, entry for "Flows Compartment", the graphical notation is missing.

A flows compartment is identified but an example is missing in Representative Notation Table 15 under 7.13.1 Connections.

An example should be added.

Representative notation table, in 7.13 Connections, uses the deprecated «equal» notation instead of the standard "=" notation for a binding connector.

All «equal» notations should be replaced with = notation.

The mapping class RSAOutputPin_Mapping should specialize OutputPin_Mapping instead of Pin_Mapping. The result pin of a ReadExtentAction is always an output pin with a defined type.

The subsections of section 7.7.2.3.7 should be ordered alphabetically.

The approved resolution to SYSML2-28 included the adding of the constraint validateAssignmentActionUsageArguments, which requires that an AssignmentActionUsage have two arguments. However, in the SysML Specification, 8.2.2.16.5 Assignment Action Usages, the AssignmentTargetParameter is optional for an AssignmentNodeDeclaration. An AssignmentActionUsage parsed without a target parameter argument will then fail the validateAssignmentActionUsageArguments.

In 7.16.9 Assignment Action Usages it states that "If the target expression of an assignment action usage is omitted, then the target is implicitly the occurrence owning the assignment action usage." However, there is no semantic constraint enforcing this, so it is not clear how the informal statement is supposed to be realized.

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.

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

Clause 9.8.8.2.13 (universalClock), Description, says

universalClock is a single Clock that can be used as a default universal time reference.

but the Time library shows it as a package-level feature, enabling everything in the universe (instances of Anything) to identify its own universal clock (see KERML-56).

The phrase "universalClock is a single Clock" above is worded as if universalClock were a part def, rather than a part usage, giving the impression of exactly one value for universalClock across all things, but there is no constraint for this. Similarly, Clause 8.4.12.6 (Accept Action Usages) says

In particular, the Occurrences::Occurrence::localClock itself defaults to the singleton universalClock (see 9.8.8.2.13 and [KerML, 9.2.12]).

and 9.7.2.2.5 (SpatialItem) says its localClock is

A local Clock to be used as the corresponding time reference within this SpatialItem. By default this is the singleton Time::universalClock.

The term "singleton" usually refers to instances of a class, rather than values of a feature, giving the impression of exactly one value for universalClock across all things.

Might be other features like this. For example, from the library:

    ISQSpaceTime::universalCartesianSpatial3dCoordinateFrame : CartesianSpatial3dCoordinateFrame[1] {
  /* A singleton CartesianSpatial3dCoordinateFrame that can be used as a default universal Cartesian 3D coordinate frame. */ }

This is also a top-level feature that seems intended to be "universal" in the sense above.

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

The OCL for the constraints deriveViewDefinitionViewCondition and deriveViewUsageViewCondition are both

viewCondition = featureMembership->
    selectByKind(ElementFilterMembership).
    condition

This is clearly wrong, since ElementFilterMemberships are not featureMemberships.

In addition, the description of the deriveViewUsageViewCondition constraint refers to ViewDefinition instead of ViewUsage, as do the descriptions of deriveViewUsageSatsifiedViewpoint, deriveViewUsageViewRendering and validateViewUsageOnlyOneViewRendering. (And the description of deriveViewUsageExposedElement is missing.)

ownedRelationship() operation. There is the following code:

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

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

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

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

The interaction FlowTransferBefore in the Transfers library package specializes both FlowTransfer and TransferBefore. Both FlowTransfer and TransferBefore are binary, so FlowTransferBefore has to be, too. However, in the normative Transfers.kerml file from the Kernel Semantic Library project, FlowTransferBefore is currently declared without owned end features, so it inherits two ends each from FlowTransfer and TransferBefore, for a total of four, which is incorrect. Instead, it needs to declare two nested end features that redefine the corresponding ends from each of the interactions it specializes.

(Note that, in subclause 9.2.7.2.3 of the specification document, FlowTransferBefore is actually documented as properly having two owned ends.)

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

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

The 2023-10 version of SysML2 still not include the XMI version of the standard libraries but only the textual syntax version.

Because of this, model elements from those libraries have no stable identifiers

The transformation does not map the Parameter::isStreaming.

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

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

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

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

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

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

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