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

ID | Project | Category | View Status | Date Submitted | Last Update
0005368 | Part 01: TTCN-3 Core Language | Technical | public | 24-09-2009 14:13 | 04-01-2010 13:18

Reporter | Anthony Baire |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v4.1.1 (published 2009-06) |
Target Version | v4.2.1 (published 2010-07) | Fixed in Version | v4.2.1 (published 2010-07) |
Clause Reference(s) | A.1.6.2.4
Source (company - Author) |

Summary | 0005368: [BNF] FromClause is ambiguous and nonsensical

Description

In TTCN-3 v3.3.x the definition of FromClause was updated so as to match the definition of ToClause. I guess the purpose of this is to support multicast operations.
v3.2 FromClause ::= FromKeyword AddressRef
v3.3 FromClause ::= FromKeyword ( AddressRef | AddressRefList | AnyKeyword ComponentKeyword )
There are three issues with this new definition:
1. It is ambiguous: in the following example:
someport.receive (somemessage) -> from (0, 1)
'(0, 1)' can be interpreted as a value list template in 'AddressRef' (meaning 0 or 1) or as a list of addresses in 'AddressRefList' (meaning 0 and 1)
2. 'AddressRefList' is nonsensical: a message cannot have multiple sources
3. 'AnyKeyword ComponentKeyword' is superfluous. If the from clause is not present, then the message can be received from any component. The two following instructions are equivalent:
someport.receive (somemessage)
someport.receive (somemessage) -> from any component
For all these reasons we suggest to revert 'FromClause' to its original definition:
FromClause ::= FromKeyword AddressRef

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
24-09-2009 14:13 | Anthony Baire | New Issue |
24-09-2009 14:13 | Anthony Baire | Status | new => assigned
24-09-2009 14:13 | Anthony Baire | Assigned To | => Ina Schieferdecker
24-09-2009 14:13 | Anthony Baire | Clause Reference(s) | => A.1.6.2.4
24-09-2009 14:13 | Anthony Baire | Source (company - Author) | =>
07-12-2009 14:21 | Ina Schieferdecker | Target Version | => Edition 4.2.1 (not yet published)
07-12-2009 14:21 | Ina Schieferdecker | Description Updated |
08-12-2009 18:00 | Ina Schieferdecker | Note Added: 0009106 |
08-12-2009 18:00 | Ina Schieferdecker | Status | assigned => closed
08-12-2009 18:00 | Ina Schieferdecker | Resolution | open => no change required
08-12-2009 18:00 | Ina Schieferdecker | Fixed in Version | => Edition 4.2.1 (not yet published)
09-12-2009 10:30 | Anthony Baire | Status | closed => feedback
09-12-2009 10:30 | Anthony Baire | Resolution | no change required => reopened
09-12-2009 10:30 | Anthony Baire | Note Added: 0009111 |
09-12-2009 11:19 | Ina Schieferdecker | Note Added: 0009114 |
04-01-2010 13:18 | Ina Schieferdecker | Status | feedback => closed
04-01-2010 13:18 | Ina Schieferdecker | Resolution | reopened => won't fix

Notes

(0009106)
Ina Schieferdecker
08-12-2009 18:00

There is a misunderstanding of the meaning of "AddressRefList" and of "AnyKeyword ComponentKeyword": it means that a message can be received from an address or from a component that matches the from clause. The CR is to be rejected.

(0009111)
Anthony Baire
09-12-2009 10:30

What I mean is that AddressRefList is superfluous here. AddressRef is defined as a template (360. AddressRef ::= TemplateInstance) and thus allows matching one source among serveral ones using a list of values (ValueOrAttribList) If we can match multiple different sources using AddressRef, then what is the exact purpose of AddressRefList?

(0009114)
Ina Schieferdecker
09-12-2009 11:19

Your CR touches upon the nature of the BNF ... the BNF includes quite some encodings of static semantics (think e.g. about the identifiers), which makes the BNF as such unparsable. It was a decision right at the beginning to develop the BNF like this, but apparently it is not only hard to implement, but also hard to read now. Anyway, we have to discuss at MTS if or not to do a major revision of the BNF. Till then we evolve the BNF along the original principles.
Wrt. your comment that "from any component" is the same as having no from clause, you are right. Still there was the decision to enable the explicit specification of that case (vs. to have an implicit specification without the from clause).