Why is the specification for TestObjective a value specification? What is the use case for making it a value specification versus a primitive string and are there any case studies/examples demonstrating the application of the an expression or opaque expression.

Figure 7.2 seems to imply that test requirements are derived from System requirements. Can we clarify the relationship between SysML requirements and UTP test requirements?

Is there a missing stereotype for instances of data ? In the conceptual section there is a mention of actual data pool which would be an instance specification of the data pool or data partition

Given the constraints applied to the <<Alternative>> construct why would we not just simply have it extend the ConditionalNode instead of StructuredActivityNode?

See section 8.5.2.3.1

Same for <<Loop>> should be restricted to loop node metaclass

<<Parallel>> seems to have a contradiction between the description and the constraint "Application in Activities
In an Activity, «Parallel» must only be applied to SequenceNode". We think that this is meant to say a Conditional Node not a sequence node.

We feel that this definitional rule should be applied to the arbitration result not the specification. 

DRAS01 It is necessary that an arbitration specification determines exactly one verdict.

We feel like there should be a relationship defined between a test case and a test objective in which the role is defined as "acceptanceCriteria" (this may be captured by the arbitration specifications and underlying expected response and check property actions) so perhaps a better role definition would be "testCaseObjective" or "goal". 

Another idea is that if we make it best practice to use test objectives to capture initial requirement success criteria then the Arbitration Specification would refine or be a lower level of abstraction in some way.

There are predefined test design techniques in the spec but don't have predefined test design technique structures to be the classifiers of the instances

Why is it that there are definitional rules for limits number of preconditions to AT MOST one, couldn't there be more than one?

There are definitional rules limiting the number of test levels and test types of a test context to AT MOST one,  think of scenarios where a test context may cover more than one type and level (the XMI shows the upper limit value to be * therefore not enforcing this rule).

Morphing should be between data pool and data partitions for a true structure morphing mapping from one format of data to another, look into other OMG specifications to bridge concepts

DRTD04 contradicts the definition of the constraint

Believe there is an error in the definition here " 8.6.1.2.4 DataProvider
Description DataProvider: A test component that is able to deliver (i.e., either select and/or generate) data according to a data specification.
The stereotype «DataProvider» is a specialization of stereotype «TestComponent». Such a test component is used to provide a data partition, represented as a Constraint extended by the stereotype «DataPartition» (SHOULD READ classifier extended by <<Data Partition>>), by generating some new data or by selecting some existing data from another data partition or a data pool according to some data specifications (represented as a Constraint extended by the stereotype 
«DataSpecification»)."

It seems that this definitional rule should not be defined as a constraint on the test procedure but actually on the TestCase

DRTP04: It is necessary that each test case invokes at least one test procedure as a main procedure invocation.

This was true for v2.1 but have not confirmed that they still exist in the xmi for v2.2

The following elements are found in the XMI file but not defined within the pdf spec:

• OpaqueProceduralElementArbitrationSpecification
• ProceduralElementASBinding
• TestCaseASBinding
• TestSetASBinding

Definitional rules don't have unique identifiers in the spec. For clarification, it would be good for these not to have repeated numbers.

Made the relationship between the arbitration result relationship to the testlogentry item, currently this is a directional relationship but made it a derived property specification for bidirectional linking therefore a tag value for verdict appears in every log entry type. We did this to make metachain queries in Cameo easier for generating a RVTM. 

Does SysmL2 drop the <<TestCase>> stereotype and to UTP2, or will it be maintained.  What’s the expectation between rectifying potential conflicts/confusion in using both in the same model?

Will SysML2 <<verify>> and UTP2 <<verifies>> stereotypes become the same eventually? This is a stereotype that seems like it could become the same in both specs if worked between groups. The different stereotypes lead to unnecessary complexity which hurts adoption for users trying to use both specs.

Section 8.3.1.4.5 describes verifies.