ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006016 | Part 01: TTCN-3 Core Language | Technical | public | 09-03-2012 10:11 | 10-08-2012 11:17

Reporter | Tomas Urban |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.3.1 (published 2011-06) |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 15.7
Source (company - Author) | Elvior

Summary | 0006016: Ambiguous rules for matching symbols for optional fields

Description

The core language specification v. 4.3.1 contains ambiguous rules for the following matching symbols: any value or none, omit and for the ifpresent attribute.
The table 11 in chapter 15.7. states that the symbols "can be assigned to templates, however when used shall be applied to optional fields of record and set types". Similar rules are provided in the annex B:
B.1.2.4 Any value or none: "It can be used on values of all types, provided that the template field is declared as optional"
B.1.2.8 Omitting optional fields: "It can be assigned to templates, but shall only be used in fields of record and set types provided that the fields are optional."
B.1.4.2 The IfPresent indicator: "This attribute may be used with all the matching mechanisms, provided this field is declared as optional."
These rules obviously forbid using the above mentioned matching symbols in any template which is not an optional record or set field. The question is, what the word "use" stands for. The might be two different interpretations:
1. "Use" means any kind of operation with the template, including assignment. (e.g. the rule in B.1.2.4 seems to suggest that)
2. "Use" means only matching operations, i.e. it is legal to assign the symbol to any template, but if the template is used for matching and it does not fulfil the criteria of being applied to an optional field, it produces an error:
type record R { integer field1 optional }
testcase TC() runs on C
{
template integer vt_1 := *;
p1.receive(R:{ field1 := vt_1 }; // legal
p1.receive(vt_1); // illegal
}
The rules specified in the chapter 15.8 seem to use the latter interpretation, because otherwise (using the former interpretation) the template(omit) restriction would make no sense (it would never be possible that the whole template resolves to omit). There are also several examples that allow assigmnent of the above mentioned matching mechanisms to a target that isn't an optional record or set field, e.g.:
// Example from chapter 15.8
template(omit) ExampleType exampleOmit := omit;
// Example 1 in 5.4.1.2
template MyMessageType MyTemplate (template integer MyFormalParam):=
{ ... }
pco1.receive(MyTemplate(omit));
Proposal:
I suggest the rules for handling the above mentioned matching mechanisms should be generalized in a dedicated chapter and made more detailed. The current rules (15.7 table 11, B.1.2.4, B.1.2.8 and B.1.4.2) shall be replaced with a reference to this chapter. The chapter shall contain the following rules:
15.7.5 Matching mechanisms for optional fields
This chapter specifies rules for the following mechanisms: omit, any value or none and ifpresent. The rules apply also to value lists and complemented value lists containing omit, any value or none or ifpresent on any level of nesting.
The matching mechanisms for optional fields can be assigned only to templates, template variables, template parameters or optional fields of record or set templates. An error shall be produced when these matching mechanisms are assigned to a field of a record of, set of, array, union or anytype template or when used inside a subset or superset.
The matching mechanisms for optional fields can be used for matching only if they are assigned to optional fields of a record or set template.
Example 1:
type record R
{
integer field1,
integer field2 optional
}
type record of integer RI;
type union U
{
integer option1,
charstring option2
}
template R t_1 (template integer p_1) :=
{
field1 := 1,
field2 := p_1
}
...
template R t_2
{
field1 := 2,
field2 := 1 ifpresent // legal: field2 is an optional record field
}
var template integer vt_1 := *; // legal: vt_1 is a template variable
var template RI vt_2 := {1, * }; // legal: * literal is interpretted as
// AnyElementOrNone
vt_2 := {1, vt_1}; // illegal: AnyValueOrNone assigned to a record of
template U t_3 := { option1 := 5 ifpresent } // illegal: ifpresent assigned to
// a union field
template integer t_4 := (1, 2, omit); // legal: AnyValueOrNone used in a value
// list; the same as (1, 2) ifpresent
p1.receive(t_1(omit)); // legal: omit used as a template parameter and the
// parameter is assigned to an optional field. Omit is
// then used for matching the optional field value.
p1.receive(vt_1); // illegal: vt_1 (containing AnyValueOrNone) is not an
// optional record field, but it is used for matching
Compared to the current specification, the suggested rules don't give any room for different interpretations, provide comprehensive and logical functionality and they are in line with other clauses (especially 15.8) and examples.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6016_resolution_v1.doc (254,464) 07-08-2012 11:39 http://oldforge.etsi.org/mantis/file_download.php?file_id=2707&type=bug CR6016_resolution_v2.doc (191,488) 09-08-2012 17:28 http://oldforge.etsi.org/mantis/file_download.php?file_id=2714&type=bug CR6016_resolution_v3.doc (200,704) 10-08-2012 11:17 http://oldforge.etsi.org/mantis/file_download.php?file_id=2717&type=bug

Issue History
Date Modified | Username | Field | Change
09-03-2012 10:11 | Tomas Urban | New Issue |
09-03-2012 10:11 | Tomas Urban | Clause Reference(s) | => 15.7
09-03-2012 10:11 | Tomas Urban | Source (company - Author) | => Elvior
16-05-2012 10:59 | Jacob Wieland - Spirent | Note Added: 0010626 |
04-07-2012 09:38 | Tomas Urban | Note Added: 0010668 |
09-07-2012 16:37 | Gyorgy Rethy | Project | Part 09: Using XML with TTCN-3 => Part 01: TTCN-3 Core Language
10-07-2012 12:13 | Gyorgy Rethy | Note Added: 0010746 |
10-07-2012 12:13 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
10-07-2012 12:13 | Gyorgy Rethy | Status | new => assigned
10-07-2012 12:13 | Gyorgy Rethy | Target Version | => Edition 4.5.1
13-07-2012 13:49 | Gyorgy Rethy | Note Added: 0010924 |
13-07-2012 14:38 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
06-08-2012 10:19 | Tomas Urban | Note Added: 0010962 |
06-08-2012 10:19 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
07-08-2012 11:39 | Gyorgy Rethy | File Added: CR6016_resolution_v1.doc |
07-08-2012 11:41 | Gyorgy Rethy | Note Added: 0010982 |
07-08-2012 11:41 | Gyorgy Rethy | Note Added: 0010983 |
07-08-2012 11:41 | Gyorgy Rethy | Note Added: 0010984 |
07-08-2012 11:41 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
09-08-2012 17:28 | Tomas Urban | File Added: CR6016_resolution_v2.doc |
09-08-2012 17:30 | Tomas Urban | Note Added: 0011013 |
09-08-2012 17:30 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
10-08-2012 10:32 | Ina Schieferdecker | Note Deleted: 0010984 |
10-08-2012 10:32 | Ina Schieferdecker | Note Deleted: 0010983 |
10-08-2012 11:17 | Ina Schieferdecker | File Added: CR6016_resolution_v3.doc |
10-08-2012 11:17 | Ina Schieferdecker | Note Added: 0011021 |
10-08-2012 11:17 | Ina Schieferdecker | Status | assigned => closed
10-08-2012 11:17 | Ina Schieferdecker | Resolution | open => fixed
10-08-2012 11:17 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1

Notes

(0010626)
Jacob Wieland - Spirent
16-05-2012 10:59

In principal I agree (though I think the same rules already are true in the current standard), but I would say that the following sentence
"The matching mechanisms for optional fields can be used for matching only if they are assigned to optional fields of a record or set template."
should be amended with "or if they are used as second argument to the match() operation when the first argument is an optional record or set field."

(0010668)
Tomas Urban
04-07-2012 09:38

Could anyone move this issue to the core language category?

(0010746)
Gyorgy Rethy
10-07-2012 12:13

STF discussion 2012-07-10: Check the issue and the proposal.

(0010924)
Gyorgy Rethy
13-07-2012 13:49

Let separate the technical side from the question, how to handle the solution in the standard's text. So, let see the technical question, where *, omit and ifpresent are allowed?
I agree, that this question is somewhat umbigous today.
As all your examples are correct, I suppose that we have a common understanding. Our understanding is that it is not an assignment vs. matching question but rather an top-level-assignment vs. field assignment vs. matching question.
So,
- at the TOP level, they are allowed to be assigned to any template (template, template var, template par) independent of the type of the template. This also includes template lists and complement lists. But not allowed in subsets and supersets, but this is defined unambiguously.
Let's borrow one of your examples:
type union U {
integer option1,
charstring option2
}
template U t_u := *; // is legal
- at the field level, they are allowed to be assigned to optional fields of record and sets only, as in your example:
template U t_3 := { option1 := 5 ifpresent } // illegal
or another example:
template R t_1 (template integer p_1) := { field1 := 1, field2 := *} //OK
template R t_1 (template integer p_1) := { field1 := *, field2 := 2} //NOK
- at the time of matching (receiving or the match operation), they can be used in optional fields of records and sets only; i.e.
p.receive (t_u) //shall cause an error
The another question is, how to specify these rules in the standard's text.
Today, we have two places in the standard, where matching mechanisms are specified: clause 15.7 an Annex B. Clause 15.7 in principle contains just a basic information and a reference to Annex B. So, we shouldn't put the above rules there, to avoid inconsistencies with Anex B (that we may have even today). It's better to keep all major rules in Annex B. But Annex B is structured according to the matching mechanisms and this is correct, if someone is searches for rules on how to use an *, he/she should find it in one place. So, what I propose to add the text clarifying the rules for each concerned matching mechanism to its own existing clause, even if this is partly a copy-paste work.
Before going on I would like to know your opinion, if the above is OK, I can continue with proposing a text.

(0010962)
Tomas Urban
06-08-2012 10:19

I think the proposed solution is very good. Since you volunteered to write the text, I will reassign the CR to you.

(0010982)
Gyorgy Rethy
07-08-2012 11:41

Propoaed resolution is uploaded in file CR6016_resolution_v1.doc. Pls. review.

(0011013)
Tomas Urban
09-08-2012 17:30

I agree with the resolution. I only change one word in three place to use the same wording as in the rest of the document. Assigned to Ina for implementation.

(0011021)
Ina Schieferdecker
10-08-2012 11:17

as proposed with editorial changes