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

ID | Project | Category | View Status | Date Submitted | Last Update
0006014 | Part 01: TTCN-3 Core Language | Technical | public | 28-02-2012 11:37 | 21-12-2012 11:34

Reporter | Bogdan Stanca-Kaposta |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | 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) | B.1.5.1
Source (company - Author) | STF 433

Summary | 0006014: Simplifications request for escaping chars inside the string pattern

Description

The rules for B.1.5.1 Set expression seems to be too complicated for both TTCN-3 developer and TTCN-3 tester (reader) and hence error prone. In this section there is no need to specify different rules, we propose a simpler formulation.
SIMPLIFIED FORMULATION START:
A list of characters enclosed by a pair of "[" and "]" matches any single character in that list. The set expression is delimited by the "[" "]" symbols. In addition to character literals, it is possible to specify character ranges using the hyphen "-" as separator. The range consist of the character immediately before the separator, the character immediately after it and all characters with a character code between the codes of the two bordering characters.
All charactern also used as metachars must also be escaped (prefixed with "\") inside set expressions if the value of that character should be allowed by that expression.
NOTE 1: Embedded lists are not allowed (for example in pattern "[ab[r-z]]" the second "[" denotes a literal "[", the first "]" closes the list and the second "]" causes an error as no related opening bracket in the pattern).
NOTE2: Using the unescaped characters: #, +, * and ? is not allowed since it does not make sense in the context.
NOTE3: To negate the set place the character "^" at the beginning of the set.
EXAMPLE: (unchanged)
template charstring RegExp1:= pattern "[a-z]"; // this will match any character from a to z
template charstring RegExp2:= pattern "[^a-z]"; // this will match any character except a to z
template charstring RegExp3:= pattern "[AC-E][0-9][0-9][0-9]YKE";
// RegExp3 will match a string which starts with the letter A or a letter between
// C and E (but not e.g. B) then has three digits and the letters YKE
SIMPLIFIED FORMULATION END:

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

Relationships

related to | 0006009 | closed | Ina Schieferdecker | Charstring Pattern Reference Parts should not be allowed
related to | 0006169 | closed | Ina Schieferdecker | The pattern char grammar has been mixed up

Attached Files

CR6014_resolution_v1.doc (116,224) 11-07-2012 17:09
http://oldforge.etsi.org/mantis/file_download.php?file_id=2678&type=bug
CR6014_resolution_v2.doc (106,496) 12-07-2012 10:54
http://oldforge.etsi.org/mantis/file_download.php?file_id=2687&type=bug
CR6014-resolution-v3.doc (109,056) 10-08-2012 14:12
http://oldforge.etsi.org/mantis/file_download.php?file_id=2720&type=bug
CR_6014_v4.docx (59,573) 14-12-2012 11:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=2784&type=bug
CR_6014_v5.docx (46,858) 21-12-2012 10:11
http://oldforge.etsi.org/mantis/file_download.php?file_id=2793&type=bug
CR_6014_v6.docx (61,680) 21-12-2012 11:33
http://oldforge.etsi.org/mantis/file_download.php?file_id=2795&type=bug

Issue History
Date Modified | Username | Field | Change
28-02-2012 11:37 | Bogdan Stanca-Kaposta | New Issue |
28-02-2012 11:37 | Bogdan Stanca-Kaposta | Clause Reference(s) | => B.1.5.1
28-02-2012 11:37 | Bogdan Stanca-Kaposta | Source (company - Author) | => STF 433
10-07-2012 13:23 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
10-07-2012 13:23 | Gyorgy Rethy | Status | new => assigned
10-07-2012 13:23 | Gyorgy Rethy | Target Version | => Edition 4.5.1
11-07-2012 17:09 | Gyorgy Rethy | File Added: CR6014_resolution_v1.doc |
11-07-2012 17:10 | Gyorgy Rethy | Note Added: 0010849 |
11-07-2012 17:16 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
12-07-2012 10:34 | Gyorgy Rethy | Note Added: 0010865 |
12-07-2012 10:37 | Gyorgy Rethy | Note Edited: 0010865 |
12-07-2012 10:41 | Gyorgy Rethy | Note Edited: 0010865 |
12-07-2012 10:54 | Bogdan Stanca-Kaposta | File Added: CR6014_resolution_v2.doc |
12-07-2012 10:59 | Bogdan Stanca-Kaposta | Note Added: 0010868 |
12-07-2012 11:01 | Bogdan Stanca-Kaposta | Note Edited: 0010868 |
12-07-2012 14:24 | Gyorgy Rethy | Note Added: 0010886 |
12-07-2012 14:25 | Gyorgy Rethy | Note Edited: 0010886 |
12-07-2012 15:32 | Gyorgy Rethy | Note Edited: 0010886 |
10-08-2012 14:12 | Jens Grabowski | File Added: CR6014-resolution-v3.doc |
10-08-2012 14:13 | Jens Grabowski | Note Added: 0011032 |
10-08-2012 14:13 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
12-12-2012 08:30 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
14-12-2012 11:16 | Tomas Urban | Relationship added | related to 0006009
14-12-2012 11:17 | Tomas Urban | Relationship added | related to 0006169
14-12-2012 11:27 | Tomas Urban | File Added: CR_6014_v4.docx |
14-12-2012 11:28 | Tomas Urban | Note Added: 0011272 |
14-12-2012 11:29 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
19-12-2012 15:24 | Bogdan Stanca-Kaposta | Note Added: 0011294 |
21-12-2012 10:11 | Gyorgy Rethy | File Added: CR_6014_v5.docx |
21-12-2012 10:13 | Gyorgy Rethy | Note Added: 0011302 |
21-12-2012 10:19 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
21-12-2012 11:32 | Ina Schieferdecker | Note Added: 0011308 |
21-12-2012 11:33 | Ina Schieferdecker | File Added: CR_6014_v6.docx |
21-12-2012 11:33 | Ina Schieferdecker | Status | assigned => resolved
21-12-2012 11:33 | Ina Schieferdecker | Resolution | open => fixed
21-12-2012 11:33 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1
21-12-2012 11:33 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010849)
Gyorgy Rethy
11-07-2012 17:10

See draft resolution text in CR6014_resolution_v1.doc.

(0010865)
Gyorgy Rethy
12-07-2012 10:34 (edited on: 12-07-2012 10:41)

Actually, the proposed simplification would mean non-backward compatible technical change and simply missing to expline all rules (i.e. creating unambiguities). Currently in the standard:
- [[] and []] are correct sets, but this is not unambiguous from the proposed text;
- the negation rule cannot be placed in a note, because this is a mandatory rule;
- it is also not explained that a ^ not in the first position does not have any specific meaning, but when in the first position, it is not member of the set list; e.g. from the proposed text it is unclear what [^^] should do; is it legal or not and what it should match?
- are empty lists and empty negated lists allowed? this is unclear from the proposal
- currently the - at the first and last positions and following a first ^ has a literal meaning, at other places it has a metacharacter meaning; but from the proposal it is unclear that e.g. what [-z] should mean? is it a legal set or an erroneous range?
- currently several metacharacers are allowed without a preceding backslash; removing this rule could invalidate existing valid TTCN-3 codes
- etc.
Pls. note that a standard is not a user guide. It shall be explicit, complete and precise to allow unambigous tool implementations.
Therefore I tried to make the text more readable but we cannot relax the completeness and the preciseness.

(0010868)
Bogdan Stanca-Kaposta
12-07-2012 10:59 (edited on: 12-07-2012 11:01)

Please note the updated document. I hope this would clarify all the questions.
These changes will eliminate the change of meaning depending on the position of a char inside a pattern.
We think the backward compatibility is not an issue since there are only theoretical relevant cases and are not used in real world implementations. The use of these existing special rules is confusing and makes code unreadable and hard to maintain.

(0010886)
Gyorgy Rethy
12-07-2012 14:24 (edited on: 12-07-2012 15:32)

Unfortunately I cannot neglect the backward compatibility problem like you do. Just the MTAS functional testing code consists of 1,5 million of TTCN-3 lines. And it is using text-based internet protocols like SIP. So, I cannot consider any changes to TTCN-3 patterns as a "theoretical relevant case". For Ericsson all non-backward compatibility cases in the language is a heavily practical issue. More detailed explanation is given in CR 6009.
So, for me still CR6014_resolution_v1.doc is the only possible resolution.
For my own curiosity, I have checked the new examples from CR6014_resolution_v1.doc in a POSIX regexp checker (http://www.zytrax.com/tech/web/regex.htm#experiment [^]) and it gave the same result as the TTCN-3 examples, including the error cases (i.e. - has no metacharacter meaning as the first or last character, escaped or following a first ^; ^ has a literal meaning when not the first character etc. So, it is difficult to claim that the current rules in the standard would be exotic or strange when all Linux/Solaris users are working with similar regex-s.

(0011032)
Jens Grabowski
10-08-2012 14:13

New trial for providing a better text. Assigned to GyÃ¶rgy for cross-checking. Please also check the examples at the end.

(0011272)
Tomas Urban
14-12-2012 11:28

This issue is a part of several related problems concerning the pattern template rules. The STF 446 has decided to solve these issues by opting for such rule that efficiently excludes any possibility of errors caused by invalid pattern format. Tool vendors can still include their own tool-specific format checks, e.g. warning users when certain characters do not form a valid metacharacters.

(0011294)
Bogdan Stanca-Kaposta
19-12-2012 15:24

a) I'm sorry but there seems that this rule added in V4.docx would make the TTCN-3 users more confuse since no errors would be delivered while compiling and the patterns would have to be validated mainly at runtime. I this this should not be the goal of a standard. b) The additional {\referenceName} rule just makes the standard even more complicated and the code less readable. STF451

(0011302)
Gyorgy Rethy
21-12-2012 10:13

It is OK with me. In CR_6014_v5.docx there are some editorial changes only: the words saying that referenced objects shall be character values and patterns only is moved to the first paragrapha of the clause, explanations of examples are moved to the EXAMPLE paragraph.

(0011308)
Ina Schieferdecker
21-12-2012 11:32

Added v6 with extended BNF rule for new "literal reference". Implemented.