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

ID | Project | Category | View Status | Date Submitted | Last Update
0005835 | Part 01: TTCN-3 Core Language | Technical | public | 30-11-2010 17:12 | 01-12-2010 16:46

Reporter | Gyorgy Rethy |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.1 (published 2011-06) | Fixed in Version | v4.3.1 (published 2011-06) |
Clause Reference(s) | B.1.5.2, A.1.6.1.3
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0005835: BNF rule for PatternElement is ambiguous, Example is wrong

Description

In the rule for PatternElement in the BNF, the last branch (PatternChar) creates an ambiguity as that can be any char and thus, every Pattern can be derived to a sequence of PatternChar, even those that should be derived by using the other alternatives in PatternElement.
Especially for those PatternElement constructs which contain more than one character, this leads to unresolvable problems (if the ambiguity is not removed somehow).
I guess the intention was that PatternChar should be any character which is not one of the characters in the "first set" of the other alternatives in PatternElement. Thus, the following characters need to be excluded "\", "?", "*", "|", "+", "[", "{", """ and "#"
Consequently, I think that the example in B.1.5.2
template charstring RegExp4 := pattern "{Reg";
should be changed to
template charstring RegExp4 := pattern "\{Reg";
Finally, it should be forbidden to use reference expressions in referenced variables/parameters/module parameters (i.e. all entities which are unknown at compile time). I.e. if a referenced charstring value contains a reference-like expression, it is treated as if it was just the sequence of the characters of the reference. Meaning: if I have a variable v which contains "{a}", then referencing it via pattern "{v}" will match only the charstring "{a}" and not any referenced 'a'. If this is the intention of the standard anyway, then it needs to be clarified.
Consequently, the stuff in EXAMPLE 3 (which is wrong in any case as it is missing at least one 'pattern') should be forbidden. But, maybe there are only some typos in Ref6, where Ref1 should be Ref4 and Ref2 should be Ref5.
I guess what the example was really supposed to be was this:
template charstring Ref0:= "My String";
template charstring Ref1:= "{Re";
template charstring Ref2:= "f0}";
template charstring Ref3:= pattern "{Ref1}{Ref2}";
//this matches "{Ref0}"
//i.e. there is no further dereferencing
//as Ref1 and Ref2 do not contain a reference
template charstring Ref4:= pattern "{Ref0}";
template charstring Ref5:= "";
template charstring Ref6:= pattern "{Ref4}{Ref5}";
//this matches "My String" â€“ here Ref0 is dereferenced, because Ref4 contains
//the reference expression {Ref0} with the reference Ref0
template charstring RegExp7 := pattern "{Reg" & "Exp1}";
//note the difference to Ref6: in this case the fragments of the
//pattern are joined before any evaluation, i.e. this template will match the string "ab"

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

Relationships

child of | 0005805 | closed | Ina Schieferdecker | BNF rule for PatternElement is ambiguous, Example is wrong

Attached Files |

Issue History
Date Modified | Username | Field | Change
30-11-2010 17:12 | Gyorgy Rethy | New Issue |
30-11-2010 17:12 | Gyorgy Rethy | Status | new => assigned
30-11-2010 17:12 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
30-11-2010 17:12 | Gyorgy Rethy | Clause Reference(s) | => B.1.5.2, A.1.6.1.3
30-11-2010 17:12 | Gyorgy Rethy | Source (company - Author) | => Testing Technologies - Jacob Wieland
30-11-2010 17:12 | Gyorgy Rethy | Issue generated from: 0005805 |
30-11-2010 17:12 | Gyorgy Rethy | Relationship added | child of 0005805
01-12-2010 16:44 | Ina Schieferdecker | Note Added: 0009904 |
01-12-2010 16:46 | Ina Schieferdecker | Status | assigned => resolved
01-12-2010 16:46 | Ina Schieferdecker | Resolution | open => fixed
01-12-2010 16:46 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.1 (not yet published)
01-12-2010 16:46 | Ina Schieferdecker | Target Version | => Edition 4.3.1 (not yet published)
01-12-2010 16:46 | Ina Schieferdecker | Status | resolved => closed

Notes

(0009904)
Ina Schieferdecker
01-12-2010 16:44

Example corrected as proposed. In addition, RegExp7 removed as this is part of Example 2 and not of Example 3.