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

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

View Issue Details

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 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