ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0006704 | Part 01: TTCN-3 Core Language | Technical | public | 27-03-2014 07:50 | 05-01-2015 16:16 |
|
| Reporter | Tomas Urban | |
| Assigned To | Gyorgy Rethy | |
| Priority | low | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | v4.5.1 (published 2013-04) | |
| Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) | |
| Clause Reference(s) | B.1.2.7 |
| Source (company - Author) | Elvior |
|
| Summary | 0006704: Number of matches of subset items |
| Description | The current specification says that a set of value can be matched by subset if it contains only elements present in the subset. It doesn't contain any restriction on the number of occurences of the elements in the set of value, in particular it doesn't say that these elements can be present only once. However, there are notes in the comments of examples pointing exactly in that direction (i.e. that subset elements can appear zero times or once in the value being matched).
Example:
Using subset(1, 2, 3) to match the value { 2, 2 }.
If the intention is to limit maximum allowed matches of individual items defined the subset to one, there should be a formal rule for it. Please notice that introducing such a rule would produce backward incompatibility, because e.g. our tool allows multiple matches. There's of course a possibility that the comments are wrong and if it is the case, they should be corrected.
|
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR6704_v1.docx (52,040) 07-10-2014 08:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=3086&type=bug
CR6704_v2.docx (54,559) 09-10-2014 09:01
http://oldforge.etsi.org/mantis/file_download.php?file_id=3123&type=bug
CR6704_v3.docx (54,022) 09-10-2014 11:52
http://oldforge.etsi.org/mantis/file_download.php?file_id=3126&type=bug
CR6704_v4.docx (54,624) 09-10-2014 15:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3132&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 27-03-2014 07:50 | Tomas Urban | New Issue | |
| 07-04-2014 13:35 | Gyorgy Rethy | Note Added: 0011936 | |
| 07-04-2014 13:35 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy |
| 07-04-2014 13:35 | Gyorgy Rethy | Status | new => assigned |
| 08-04-2014 17:05 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06) |
| 30-04-2014 08:55 | Jacob Wieland - Spirent | Note Added: 0012056 | |
| 06-10-2014 15:41 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban |
| 06-10-2014 15:41 | Gyorgy Rethy | Priority | normal => low |
| 07-10-2014 08:51 | Tomas Urban | File Added: CR6704_v1.docx | |
| 07-10-2014 08:56 | Tomas Urban | Note Added: 0012242 | |
| 07-10-2014 08:56 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy |
| 07-10-2014 08:56 | Tomas Urban | Status | assigned => confirmed |
| 07-10-2014 10:25 | Jacob Wieland - Spirent | Note Added: 0012249 | |
| 08-10-2014 08:23 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch |
| 09-10-2014 09:01 | Axel Rennoch | File Added: CR6704_v2.docx | |
| 09-10-2014 09:06 | Axel Rennoch | Note Added: 0012308 | |
| 09-10-2014 09:06 | Axel Rennoch | Assigned To | Axel Rennoch => Tomas Urban |
| 09-10-2014 09:06 | Axel Rennoch | Status | confirmed => assigned |
| 09-10-2014 09:07 | Axel Rennoch | Note Added: 0012309 | |
| 09-10-2014 09:07 | Axel Rennoch | Status | assigned => confirmed |
| 09-10-2014 11:26 | Tomas Urban | Note Added: 0012313 | |
| 09-10-2014 11:52 | Tomas Urban | File Added: CR6704_v3.docx | |
| 09-10-2014 11:54 | Tomas Urban | Note Added: 0012314 | |
| 09-10-2014 11:54 | Tomas Urban | Assigned To | Tomas Urban => Axel Rennoch |
| 09-10-2014 12:33 | Jacob Wieland - Spirent | Note Added: 0012320 | |
| 09-10-2014 15:50 | Axel Rennoch | File Added: CR6704_v4.docx | |
| 09-10-2014 15:51 | Axel Rennoch | Note Added: 0012329 | |
| 09-10-2014 15:51 | Axel Rennoch | Assigned To | Axel Rennoch => Tomas Urban |
| 09-10-2014 15:51 | Axel Rennoch | Status | confirmed => assigned |
| 09-10-2014 15:52 | Axel Rennoch | Note Added: 0012330 | |
| 09-10-2014 15:52 | Axel Rennoch | Status | assigned => confirmed |
| 09-10-2014 16:00 | Tomas Urban | Note Added: 0012331 | |
| 09-10-2014 16:00 | Tomas Urban | Status | confirmed => resolved |
| 09-10-2014 16:00 | Tomas Urban | Resolution | open => fixed |
| 09-10-2014 16:00 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy |
| 05-01-2015 16:16 | Gyorgy Rethy | Note Added: 0012620 | |
| 05-01-2015 16:16 | Gyorgy Rethy | Status | resolved => closed |
| 05-01-2015 16:16 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06) |
|
Notes |
|
|
|
|
STF478, 2014-04-07: Check the text, no more than one matching is allowed. Check text and propose correction. |
|
|
|
|
|
since the 'set of' in TTCN-3 is a mathematical 'bag' (i.e. multi-set where each element can occur multiple times), the subset and superset constructions should also adhere to this semantics. Otherwise, the language would become inconsistent and it would be impossible to match for a minimum/maximum number of occurrences of the same element or different elements matching the same template. |
|
|
|
|
Proposal uploaded. It contains a rule for the SuperSet matching mechanism too in order to keep uniform style and remove any possibility of different interpretations. I didn't provide any examples, but I think the notes explain the added rules sufficiently.
Please check. |
|
|
|
|
The wording, unfortunately, is still ambiguous.
As it is written in the proposal, it would enforce that for each subset/superset-element that is matching an element of the set-of value, it is not allowed to match another one. This, of course, is not the intention.
Maybe it should be described in a more mathematical fashion, i.e.
For superset:
- there exists an one-to-one mapping from the superset-elements to the elements of the set-of-value so that the superset-element matches the set-of-element it is mapped to.
For subset:
- there exists a one-to-one mapping from the elements of the set-of-value to the superset-elements so that the set-of element is matched by the superset-element it is mapped to.
Of course, in both cases, there can be more than one of these mappings, i.e. the match can be ambiguous. |
|
|
|
|
|
The situation appears to be solved by the additional text in the uploaded proposal. However the notes may be substituted by the "mathematical" explanations proposed by Jacob. I also do not see a need for additional examples. |
|
|
|
|
|
Second upload exchanges only the notes. |
|
|
|
|
|
I think that Jacob's arguments are valid. The current wording is indeed too restrictive. E.g. having a superset (?, 2) and set of { 1, 2 }, the second element of the set is matched by both superset items. It means that the successful matches are not distinct as required by the proposed rule. I will update the proposal. |
|
|
|
|
|
Updated according to Jacob's proposal. Please check. |
|
|
|
|
Except for the 'between's which should be 'from's this is fine.
A one-to-one-mapping *between* two sets - in my opinion - is a bijective mapping (i.e. also surjectivel, i.e. A and B have the same size), while a one-to-one mapping *from* set A to set B needs only to be injectve (i.e. B can have more elements than A) |
|
|
|
|
|
wording change to reflect mapping as non-bijective |
|
|
|
|
|
final wording to be confirmed |
|
|
|
|
|
I have no objections. The proposed resolution is ready to be added to the next version of the TTCN-3 core language standard. |
|
|
|
|
|