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

ID | Project | Category | View Status | Date Submitted | Last Update
0006017 | Part 01: TTCN-3 Core Language | Technical | public | 16-04-2012 19:54 | 06-08-2012 17:22

Reporter | Andras Kovacs |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.5.1 (published 2013-04) | Fixed in Version | v4.5.1 (published 2013-04) |
Clause Reference(s) | 15.11, A.1.6.
Source (company - Author) | STF433

Summary | 0006017: [Part 01: TTCN-3 Core Language] BNF ambiguity for concatenation of string templates
Description | BNF 88, 89, and 90 are conflicting: MatchingSymbol definition allows CharStringMatch, which allows & (BNF 109) but BNF 88 also allows & for the template construction Therefore the interpretation of the BNF rules is ambiguous.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR_6017_resolution_v1.docx (44,400) 13-07-2012 14:04 http://oldforge.etsi.org/mantis/file_download.php?file_id=2701&type=bug

Issue History
Date Modified | Username | Field | Change
16-04-2012 19:54 | Andras Kovacs | New Issue |
16-04-2012 19:54 | Andras Kovacs | Clause Reference(s) | => 15.11, A.1.6.
16-04-2012 19:54 | Andras Kovacs | Source (company - Author) | => STF433
19-04-2012 11:44 | Jacob Wieland - Spirent | Note Added: 0010559 |
09-07-2012 16:54 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
10-07-2012 12:02 | Gyorgy Rethy | Note Added: 0010745 |
10-07-2012 12:02 | Gyorgy Rethy | Assigned To | => Tomas Urban
10-07-2012 12:02 | Gyorgy Rethy | Status | new => assigned
10-07-2012 12:02 | Gyorgy Rethy | Target Version | => Edition 4.5.1
12-07-2012 11:35 | Tomas Urban | Note Added: 0010871 |
12-07-2012 11:35 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
13-07-2012 10:11 | Gyorgy Rethy | Note Added: 0010910 |
13-07-2012 10:12 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
13-07-2012 14:04 | Tomas Urban | File Added: CR_6017_resolution_v1.docx |
13-07-2012 14:06 | Tomas Urban | Note Added: 0010926 |
13-07-2012 14:07 | Tomas Urban | Assigned To | Tomas Urban => Ina Schieferdecker
13-07-2012 14:07 | Tomas Urban | Status | assigned => resolved
06-08-2012 17:22 | Ina Schieferdecker | Note Added: 0010978 |
06-08-2012 17:22 | Ina Schieferdecker | Status | resolved => closed
06-08-2012 17:22 | Ina Schieferdecker | Resolution | open => fixed
06-08-2012 17:22 | Ina Schieferdecker | Fixed in Version | => Edition 4.5.1

Notes

(0010559)
Jacob Wieland - Spirent
19-04-2012 11:44

As far as I remember, this is restricted by comments at the various rules.

(0010745)
Gyorgy Rethy
10-07-2012 12:02

STF discussion 2012-07-10: Check the issue.

(0010871)
Tomas Urban
12-07-2012 11:35

The BNF rule numbers used in the original CR are related to the standard version 4.3.1. In the most recent standard, the mentioned rules are numbered as follows:
91.SimpleSpec ::= (SingleExpression ["&" SimpleTemplateSpec]) | SimpleTemplateSpec
92.SimpleTemplateSpec ::= CharStringMatch | (SingleTemplateExpression ["&" SimpleSpec])
93.SingleTemplateExpression ::= MatchingSymbol | (TemplateRefWithParList [ExtendedFieldReference])
112.CharStringMatch ::= PatternKeyword PatternParticle {"&" PatternParticle}
I think the possible conflict is a question of BNF interpretation. E.g. pattern "abc" & v_ref1 can be indeed resolved in two ways, either using 91, 92 and 112 (interpretting v_ref1 as a PatternParticle from the rule 112) or using rules 91, 92, 93, 112, 92 and 91 (interpretting v_ref1 as SimpleSpec from the rule 92).
However, BNF are usually interpretted so that the lower lying rules take precedence over parent rules. This is similar to the standard way of resolving shift/reduce conflicts in parsers when shift is prefered over reduce. Thus, v_ref1 from the example shall be always interpretted as a PatternParticle.
In my opinion the BNF rules are written correctly and there's no need to change them in order to avoid this kind of conflict. Nevertheless, I think that there is one change that can be made:
Rule 92 can be simplified by removing CharStringMatch, because the second part of the rule already includes it (SingleTemplateExpression -> MatchingSymbol -> CharStringMatch).
GyÃ¶rgy, could you please add your comment on this?

(0010910)
Gyorgy Rethy
13-07-2012 10:11

I agree with your assumption. Actually, if I got the original reported issue correctly, removing CharStringMatch from SimpleTemplateSpec will also solve the original problem.

(0010926)
Tomas Urban
13-07-2012 14:06

Resolved as requested. Please check.

(0010978)
Ina Schieferdecker
06-08-2012 17:22

as proposed