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

ID | Project | Category | View Status | Date Submitted | Last Update
0006812 | Part 06: TTCN-3 Control Interface | New Feature | public | 05-11-2014 15:58 | 26-01-2015 11:39

Reporter | Tomas Urban |
Assigned To | Tomas Urban |
Priority | normal | Severity | feature | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 7.2.2
Source (company - Author) | STF 478

Summary | 0006812: Abstract data classes for matching mechanisms

Description

During resolving several CRs in the past (e.g. 0006793), it was repeatedly proposed that the TCI should contain dedicated classes for TTCN-3 matching mechanisms so that TCI users can access properties of the matching mechanisms via dedicated methods and even change these properties if needed.
While the current version of the TCI contains crude read access (through a text conversion) that might be acceptable (but not comfortable to use) for TCI-TL or analysis of in template parameters of external functions is xTRI, it is not usable for building templates outside of the TE. Thus it e.g. not possible to modify out/inout template parameters in external functions or set the content of template parameters of test cases in TCI-TM (unless they contain no matching mechanism).
This CR attempts to change that, introducing a new set of dedicated abstract TCI data classes and modifying the existing ones that allow the users to work with TTCN-3 templates in TCI without any restriction.

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

Relationships

related to | 0006793 | closed | Tomas Urban | Value Interface is underspecified/inconsistent for Templates

Attached Files

CR6812_v1.docx (83,016) 05-11-2014 15:59
http://oldforge.etsi.org/mantis/file_download.php?file_id=3167&type=bug
CR6812_v2.docx (82,132) 06-11-2014 09:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3169&type=bug
CR6812_v3.docx (112,198) 07-11-2014 12:31
http://oldforge.etsi.org/mantis/file_download.php?file_id=3185&type=bug
CR6812_v4.docx (163,392) 16-12-2014 14:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3203&type=bug

Issue History
Date Modified | Username | Field | Change
05-11-2014 15:58 | Tomas Urban | New Issue |
05-11-2014 15:58 | Tomas Urban | Status | new => assigned
05-11-2014 15:58 | Tomas Urban | Assigned To | => Tomas Urban
05-11-2014 15:58 | Tomas Urban | Relationship added | related to 0006793
05-11-2014 15:59 | Tomas Urban | File Added: CR6812_v1.docx |
05-11-2014 16:02 | Tomas Urban | Note Added: 0012436 |
06-11-2014 07:51 | Tomas Urban | Summary | Abstract data classes for matching mechanims => Abstract data classes for matching mechanisms
06-11-2014 09:00 | Tomas Urban | File Added: CR6812_v2.docx |
06-11-2014 09:02 | Tomas Urban | Note Added: 0012447 |
06-11-2014 09:24 | Gyorgy Rethy | Note Added: 0012448 |
06-11-2014 09:24 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
06-11-2014 09:25 | Gyorgy Rethy | Assigned To | Tomas Urban => Jens Grabowski
06-11-2014 14:17 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
07-11-2014 10:15 | Jacob Wieland - Spirent | Note Added: 0012480 |
07-11-2014 10:26 | Tomas Urban | Note Added: 0012481 |
07-11-2014 10:31 | Jacob Wieland - Spirent | Note Added: 0012482 |
07-11-2014 10:32 | Tomas Urban | Note Added: 0012483 |
07-11-2014 10:33 | Jacob Wieland - Spirent | Note Added: 0012484 |
07-11-2014 10:39 | Jacob Wieland - Spirent | Note Added: 0012485 |
07-11-2014 10:45 | Jacob Wieland - Spirent | Note Added: 0012486 |
07-11-2014 10:48 | Jacob Wieland - Spirent | Note Added: 0012487 |
07-11-2014 11:16 | Tomas Urban | Note Added: 0012488 |
07-11-2014 11:21 | Tomas Urban | Note Added: 0012489 |
07-11-2014 12:31 | Tomas Urban | File Added: CR6812_v3.docx |
07-11-2014 12:33 | Tomas Urban | Note Added: 0012492 |
07-11-2014 13:28 | Jacob Wieland - Spirent | Note Added: 0012496 |
07-11-2014 13:32 | Jacob Wieland - Spirent | Note Added: 0012497 |
15-12-2014 10:03 | Tomas Urban | Note Added: 0012551 |
15-12-2014 16:54 | Jacob Wieland - Spirent | Note Added: 0012552 |
16-12-2014 07:53 | Tomas Urban | Note Added: 0012553 |
16-12-2014 08:16 | Tomas Urban | Note Edited: 0012553 | bug_revision_view_page.php?bugnote_id=12553#r102
16-12-2014 14:23 | Tomas Urban | File Added: CR6812_v4.docx |
16-12-2014 14:27 | Tomas Urban | Note Added: 0012554 |
16-12-2014 14:27 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
16-12-2014 14:27 | Tomas Urban | Status | assigned => confirmed
16-12-2014 14:35 | Jacob Wieland - Spirent | Note Added: 0012555 |
06-01-2015 10:17 | Jens Grabowski | Note Added: 0012635 |
06-01-2015 10:17 | Jens Grabowski | Status | confirmed => resolved
06-01-2015 10:17 | Jens Grabowski | Resolution | open => fixed
06-01-2015 10:17 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
06-01-2015 10:18 | Tomas Urban | Note Added: 0012636 |
06-01-2015 10:18 | Tomas Urban | Status | resolved => closed
26-01-2015 11:39 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)

Notes

(0012436)
Tomas Urban
05-11-2014 16:02

Jacob, I added you as a monitoring user as you showed particular interest in TCI data types for matching symbols. If you have time, could you please quickly review the concept? There's no mapping at the moment, I would first like stabilize the draft before I go on with it.

(0012447)
Tomas Urban
06-11-2014 09:02

Minor corrections: - removed inclusive flag from the LengthRestriction abstract data class (see 0006811 for more details) - removed length restriction from permutations

(0012448)
Gyorgy Rethy
06-11-2014 09:24

If this CR is succeeded be agreed this year, it replaces 6793, if not, then 6793 will be implemented in V4.7.1 and this CR is moved for the next edition.

(0012480)
Jacob Wieland - Spirent
07-11-2014 10:15

I don't understand the following: "void removePermutation(TInteger index) Removes the permutation at the specified index. The allowed index range is from 0 to (getPermutationCount() – 1). No elements are removed from the record of by this operation. When the operation completes, the existing elements at positions specified by the removed permutation don’t belong to any permutation."

(0012481)
Tomas Urban
07-11-2014 10:26

// Let's have the following record-of template:
rec = {0, 1, 2, 3, 4, 5};
// We create a permutation:
Permutation permutation = new Permutation(); // TCI should actually contain a factory method - I will specify that
permutation.setStartPosition(1);
permutation.setLength(2);
// Now we add permutation to the template:
rec.addPermutation(permutation);
// the record-of is now { 0, permutation(1, 2), 3, 4, 5}
// rec.getPermutationCount returns 1
// If we want to remove the permuation, we call:
rec.removePermutation(0);
// the record-of is now again { 0, 1, 2, 3, 4, 5 }
// the elements that belonged to the permutation (1, 2) are not deleted
// only the permutation "wrapper" disappears

(0012482)
Jacob Wieland - Spirent
07-11-2014 10:31

In proposed section 7.2.2.3.2.
"void insert(Value item, TInteger position)
Inserts the item to the specified position inside the the matching list, replacing the original item. The matching list doesn’t change its size during this operation."
Why do you call an overwriting function "insert"? For insertion, I would expect the length to change by one. Also, it should be restricted to the positions already available, I guess.
I propose to either change the name to set or setItem if it shall keep the proposed semantics (I would prefer that option as then you have a get/set pair) or to change the semantics to an insert-semantics if it shall keep the name.

(0012483)
Tomas Urban
07-11-2014 10:32

Yes, that's absolutely correct. It is actually corrected in the work version of the document.

(0012484)
Jacob Wieland - Spirent
07-11-2014 10:33

Also, the following paragraph is doubled (in section 7.2.2.3.2) " void get(TInteger position) Returns the value or template at the specified position inside the matching mechanism. "

(0012485)
Jacob Wieland - Spirent
07-11-2014 10:39

Just a question: are length restrictions like length(1..4, 7 .. 8, 10 .. infinity) not allowed in TTCN-3? If they are allowed, then the LengthRestriction should be a ListMatching as well and just contain a list of number or ranges.

(0012486)
Jacob Wieland - Spirent
07-11-2014 10:45

The Permutation modelling seems a bit weird to me. Anyway, it should be restricted that permutations cannot overlap, i.e. the range between startPos..startPos+length-1 of one permutation shall not intersect with the range startPos..startPos+length-1 of another permutation attached to the same RecordOfValue.

(0012487)
Jacob Wieland - Spirent
07-11-2014 10:48

In section 7.2.2.4.1, the possibility to model -infinity is missing. Since ranges are not used only for lengths but also for integer types that can include negative infinity, this needs to be added.

(0012488)
Tomas Urban
07-11-2014 11:16

Minus infinity support is context dependent. If the RangeBoundary is used as a lower range and set to infinity, it will be interpreted as -infinity.

(0012489)
Tomas Urban
07-11-2014 11:21

The current version of the core language specification allows only a single range to be used in the length restriction.

(0012492)
Tomas Urban
07-11-2014 12:33

Interim draft uploaded. It contains several additions and corrections base on the received feedback and java mapping. C, C++ and C# mapping are still missing.

(0012496)
Jacob Wieland - Spirent
07-11-2014 13:28

The abstract TTCN-3 type and value representation consist of two parts should be changed into ... consists of the following parts

(0012497)
Jacob Wieland - Spirent
07-11-2014 13:32

Also, there is no (direct) way to create an omit-template. I think omit needs to be added to the MatchingSymbols list.

(0012551)
Tomas Urban
15-12-2014 10:03

Omit templates are intentionally left out because of dual meaning of the omit symbol. The current proposal expects that omit is represented in the same way as in case of omitted values, i.e. that the notPresent function returns true. I will add a note to the proposal.

(0012552)
Jacob Wieland - Spirent
15-12-2014 16:54

That is okay, my question is about creating an omit template as root. Creating one as a field of a record/set template is already possible, of course.

(0012553)
Tomas Urban
16-12-2014 07:53 (edited on: 16-12-2014 08:16)

I think I understand what you mean. In the current specification, there are only two ways on how to set a value to omit: either using RecordValue.setFieldOmitted or creating a blank new value by calling Type.newInstance.
Introducing a new matching symbol for top-level omit is possible in general. However, before we decide in its favor, we should consider the consequences. The main problem is that such a matching symbol is not compatible with the representation of omit assigned to record fields. There are two possible ways to resolve this problem:
1. Introduce the dedicated matching symbol and a rule saying that assigning MatchingMechanism(OMIT) to an optional field of a record value (by calling RecordValue.setField) is the same as calling RecordValue.setFieldOmitted for the same field.
2. No new matching symbol and allow to explicitly create omit from existing instances by a new function Value.setNotPresent. The function would control the Value.notPresent property which is currently available only for reading.
Which of the approaches would you prefer?

(0012554)
Tomas Urban
16-12-2014 14:27

Complete version of the proposal is ready now. Jens, could you please check it?

(0012555)
Jacob Wieland - Spirent
16-12-2014 14:35

I think setNotPresent sounds fine to me.

(0012635)
Jens Grabowski
06-01-2015 10:17

Ok for me.

(0012636)
Tomas Urban
06-01-2015 10:18

Added to the TCI specification draft.