The empty sections 8.7.1 Arbitration Specifications and section 8.7.1.1 Arbitration Facility are relicts from UTP 2.1. They should be removed from the editorial contents of the spec. This will cause a renumbering of current section 7.2 to 7.1 and current section 7.3 to 7.2. The renumbering affects all subsection of these two sections transitively.

The arbitration specification binding mechanism that was introduced in UTP 2.2 supersedes the former binding of arbitration specifications directly from the stereotypes. This direct binding is deprecated (since it does not scale) and should be marked as such. It should be kept nonetheless for backward compatibility

The caption says "estSetArbitrationSpecification" but it should be "TestSetArbitrationSpecification".

The icons for the stereotypes should be added to the specification as a non-normative attachment.
Files for Icons would allow the specification to have a default set of common icons associated with the stereotypes, enabling users to use them without creating their own icons. This would also create a de facto style to aid in the adoption and consistency of implementations.

Note that icons should be provided as SVG. There is also a mechanism to include these icons in the XMI, but the SVG should also be a zipped attachment to the public non-normative attachments.

[ES20311903]

the correct link is

https://www.etsi.org/deliver/etsi_es/203100_203199/20311903/01.05.01_60/es_20311903v010501p.pdf

Graphics do not align between the UTP spec and the XMI.

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?

Test planning should incorporate schedule and budget. Should it have the equivalent of a Gantt chart? How do we incorporate a time phased approach and get that embedded into the standard? TestExecutionSchedule helps allude to schedule, but the spec would benefit from more thought on this.

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.

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

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

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

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

How do we handle that a test item is a part of a particular system? How can we point to a part property of a composite structure? Can we use dot notation to say my test item is not just the type OpticalSensor but the UAV.PayloadCage.OpticalSensor ?

Why does the UTP not specify InstanceSpecifications of test configurations?  Perhaps we handle this through the test log structure to have test log entries that are instances of test configurations.

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.

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

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

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.