ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006793 | Part 06: TTCN-3 Control Interface | Clarification | public | 27-08-2014 13:15 | 17-12-2014 11:43

Reporter | Jacob Wieland - Spirent |
Assigned To | Tomas Urban |
Priority | high | Severity | major | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2014-06) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 7.2.
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0006793: Value Interface is underspecified/inconsistent for Templates

Description

In section 7.2 of the TCI standard, the value interface is introduced for the purpose of encoding and decoding:
"The TCI specification defines a set of abstract data types. These describe, at a very high level, which kind of data shall be passed from a calling to a called entity. The abstract data types are used to determine:
•
how TTCN-3 data is passed from a TE to an encoder, to encode TTCN-3 value representations into a bitstring;
and in the reverse case;
•
how data passed from a decoder to the TE shall be decoded from a bitstring into its TTCN-3 value
representation"
In section 7.2.2 it is stated:
"The abstract TTCN-3 type and value representation consists of two parts:
•
an abstract data type
Type
that represents all TTCN-3 types in a TTCN-3 module;
•
different abstract data types that represent TTCN-3 values, i.e. TTCN-3 values of a given TTCN-3 type. This
can be either values of TTCN-3 predefined types or of TTCN-3 user-defined types."
This suggests that only value instances (not templates) are to be handled via these interfaces (and neglects the fact that templates can also be passed to external functions as parameters).
In section 7.2.2.2. however, two additional non-mandatory functions are introduced (I guess this was added later) that contradict the above statement:
"In addition,
Value
can be used to represent matching mechanisms, which are used instead or inside values e.g. in
template parameters or for template variables. Two additional operations:
isMatchingSymbol
(returns true for
matching symbols) and
valueToString (
for printing value content in the same way as the log operation; can be
used for displaying value content) are defined. These operations are not mandatory - it is up to a tool vendor to support
them or not"
The following definitions in section 7.2.2.2 of methods on Values (except the two just mentioned) all seem to take the first statement for granted, i.e. that they are invoked on TTCN-3 values only.
For instance, the semantics of the function getField() in section 7.2.2.2.11 is defined using the term length which is only defined for values and for omit (if taken from the function getLength()). Therefore, in our opinion, the term length for templates is unspecified. Several interpretations are possible, but are not specifically stated by the standard.
Other functions for accessing parts of values (i.e. in string-values and especially in numeric-types) are also unspecified for Templates.
A clarification of these inconsistencies/underspecifications would be helpful.
For backward compatibility for our customers, we would favor the interpretation that getLength() for a list-value-notation template should give the number of items in the notation and getField(i) should give back the item at the given position i, even if items up to i are AnyElementsOrNone or Permutation which would count as a single item in regard to position. Though this would not be consistent with the lengthof() function and the index-notation in the TTCN-3 core language, it would be helpful for exploring such templates. (Otherwise, another way of exploration should be added to the standard).
As already stated in CR 6448, a better template interface for exploring (or even building) templates (other than isMatchingSymbol and valueToString) is still needed.
If the above interpretation for getLength() and getField() of RecordOfValue is not possible and the Value interface (except isMatchingSymbol and valueToString) shall only be applicable for actual TTCN-3 values and not templates, then it should at least be stated so specifically to avoid future misinterpretations.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006448 | closed | Ina Schieferdecker | Part 01: TTCN-3 Core Language | Rules for external function parameters
related to | 0006812 | closed | Tomas Urban | Part 06: TTCN-3 Control Interface | Abstract data classes for matching mechanisms

Attached Files | CR6793_v1.docx (49,652) 07-10-2014 14:41 http://oldforge.etsi.org/mantis/file_download.php?file_id=3097&type=bug CR6793_v2.docx (50,105) 08-10-2014 16:05 http://oldforge.etsi.org/mantis/file_download.php?file_id=3118&type=bug

Issue History
Date Modified | Username | Field | Change
27-08-2014 13:15 | Jacob Wieland - Spirent | New Issue |
27-08-2014 13:17 | Jacob Wieland - Spirent | Relationship added | related to 0006448
06-10-2014 10:53 | Gyorgy Rethy | Note Added: 0012223 |
06-10-2014 10:53 | Gyorgy Rethy | Assigned To | => Tomas Urban
06-10-2014 10:53 | Gyorgy Rethy | Status | new => assigned
07-10-2014 14:41 | Tomas Urban | File Added: CR6793_v1.docx |
07-10-2014 14:44 | Tomas Urban | Note Added: 0012254 |
07-10-2014 14:44 | Tomas Urban | Status | assigned => confirmed
07-10-2014 14:44 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
07-10-2014 16:10 | Jacob Wieland - Spirent | Note Added: 0012261 |
08-10-2014 08:13 | Gyorgy Rethy | Note Added: 0012264 |
08-10-2014 08:13 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
08-10-2014 08:59 | Tomas Urban | Note Added: 0012266 |
08-10-2014 15:46 | Jacob Wieland - Spirent | Note Added: 0012288 |
08-10-2014 16:05 | Tomas Urban | File Added: CR6793_v2.docx |
08-10-2014 16:07 | Tomas Urban | Note Added: 0012293 |
08-10-2014 16:07 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
08-10-2014 16:45 | Jacob Wieland - Spirent | Note Added: 0012305 |
09-10-2014 09:00 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
09-10-2014 09:00 | Gyorgy Rethy | Status | confirmed => resolved
09-10-2014 09:00 | Gyorgy Rethy | Resolution | open => fixed
09-10-2014 09:00 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)
05-11-2014 15:58 | Tomas Urban | Relationship added | related to 0006812
17-12-2014 11:43 | Tomas Urban | Note Added: 0012561 |
17-12-2014 11:43 | Tomas Urban | Status | resolved => closed

Notes

(0012223)
Gyorgy Rethy
06-10-2014 10:53

For checking the problem.

(0012254)
Tomas Urban
07-10-2014 14:44

I think there's a misunderstanding in the interpretation of the rules added to TCI specification ver. 4.5.1. The dedicated abstract data types (such as RecordOfValue) were never intended to manipulate with matching mechanisms. So your assumption that "the definitions in section 7.2.2.2 of methods on Values (except the two just mentioned) all seem to take the first statement for granted, i.e. that they are invoked on TTCN-3 values only" is absolutely correct.
The whole idea was that the data objects representing matching mechanisms are instances of the base Value abstract data type and never instances of the dedicated abstract data types, i.e. whenever the isMatchingSymbol operation returns true, the object cannot be cast to the dedicated abstract data type.
This is a lightweight solution addressing the issue that there was absolutely no mechanism for representing templates occurring in parameters etc. I agree with you that a fully fledged framework for getting and modifying all possible properties of matching mechanisms would be needed, however it hasn't been so far implemented because of time constraints.
In the attached proposal, I only addressed the issue raised in the CR and added some rules that leave less space for distinct interpretations. I assign the problem to György for cross-checking and I would like to hear your comments Jacob as well.

(0012261)
Jacob Wieland - Spirent
07-10-2014 16:10

I have a problem with this NOTE:
"Constructive values such as records, sets, records of, sets of, arrays, unions and anytype values might contain a matching mechanism in one of their elements and still return false. In this case, it is always possible to use the dedicated abstract data type operations to access individual elements of the constructive value."
It contradicts the preceding definition:
"... returns true if ..."
"It is a record of, set of or array value containing a matching mechanism specified in clauses B.1.3.2 or B.1.3.3 of ES 201 8731 [1] in one of its elements"
Also, since the only specified way for accessing parts of RecordOfValue is the getField method which is dependent on the length, how is the semantics of length and getField for such a template-instance, e.g. if there is a AnyElementsOrNone in the list. It clearly must be different from the semantics of lengthof() and the index-notation (which are undefined in that case). This would have to be specified.
Thus, I would either strike that NOTE or we need further specification.

(0012264)
Gyorgy Rethy
08-10-2014 08:13

Pls. check Jacob's comment.

(0012266)
Tomas Urban
08-10-2014 08:59

What contradiction do you see there? Could you please be more specific, because I couldn't find any.
B.1.3.2 describes AnyElementsOrNone and B.1.3.3 describes permutation. As you know, a whole set of complicated rules is then used in the core language standard for length calculations and element access. The current TCI avoid these rules. According to the specification, the RecordOfValue and SetOfValue data types cannot be used for records of, sets of and arrays containing the mentioned matching mechanisms. Only the general Value data type is granted for these templates. This means that element access is not possible in these cases at all, because there's never an instance with a getField method.
However, records of, sets of and arrays containing other matching mechanisms in their elements (e.g. AnyElement, range, pattern etc.) can be represented by a RecordOfValue and SetOfValue instance as there are no side effects on the length calculation and field access. And this is exactly the situation the note describes.
Example:
type record of integer RoI;
template RoI m_t1 := { 1, * };
// cannot be transformed to RecordOfValue, because it contains AnyElementsOrNone
// transformed to Value, isMatchingSymbol returns true
template RoI m_t2 := { 2, ?, 6}
// can be transformed to RecordOfValue, isMatchingSymbol returns false
// RecordOfValue.getField(0) returns an IntegerValue instance
// RecordOfValue.getField(1) returns a Value instance with isMatchingSymbol
// returning true

(0012288)
Jacob Wieland - Spirent
08-10-2014 15:46

Ah, I didn't catch the restriction to clauses B.1.3.2 and B.1.3.3 (maybe that should be spelled out to AnyElementsOrOne and Permutation)

(0012293)
Tomas Urban
08-10-2014 16:07

I added a new version of the proposal that contains names of the concerned matching mechanisms too. I hope it helps to increase readability of the rules.

(0012305)
Jacob Wieland - Spirent
08-10-2014 16:45

Thanks, much more readable.

(0012561)
Tomas Urban
17-12-2014 11:43

Added to the TCI specification draft 4.6.2.