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

ID | Project | Category | View Status | Date Submitted | Last Update
0005923 | Part 01: TTCN-3 Core Language | Editorial | public | 22-08-2011 15:23 | 29-11-2011 15:52

Reporter | Andrus Lehtmets |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | TTCN-3 Edition 4.3.1: Core language
Source (company - Author) | Elvior

Summary | 0005923: BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match

Description

BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match
Chapter 6.2.9
type port PortTypeIdentifier message "{"
[ address Type â€œ;â€ ]
[ map param "(" { FormalValuePar [","] }+ ")" ]
[ unmap param "(" { FormalValuePar [","] }+ ")" ]
{ ( in | out | inout ) { MessageType [ "," ] }+ ";" }
"}"
Procedure-based port:
type port PortTypeIdentifier procedure "{"
[ address Type â€œ;â€ ]
[ map param "(" { FormalValuePar [","] }+ ")" ]
[ unmap param "(" { FormalValuePar [","] }+ ")" ]
{ ( in | out | inout ) { Signature [ "," ] }+ ";" }
"}"
50.MessageAttribs ::= MessageKeyword "{" [AddressDecl] {MessageList [SemiColon]}+
"}" [MapKeyword ParamKeyword "(" FormalValuePar
{"," FormalValuePar} ")"] [UnmapKeyword ParamKeyword
"(" FormalValuePar
{"," FormalValuePar}
")"]
58.ProcedureAttribs ::= ProcedureKeyword "{" [AddressDecl] {ProcedureList
[SemiColon]}+
"}" [MapKeyword ParamKeyword "(" FormalValuePar
{"," FormalValuePar} ")"] [UnmapKeyword ParamKeyword
"(" FormalValuePar
{"," FormalValuePar}
")"]

Steps To Reproduce |

Additional Information

Ina: The syntactical structure in the main text only explains the principles of the syntactic elements â€“ it does not define the syntax itself â€“ it is only used to give the reader an indication how the syntax looks like. Wrt. to the usage of parameters in map/unmap and the described cases, please also create CRs.
TomÃ¡Å¡ Urban: but it should be corrected anyway, because it gives the reader totally wrong impression where to put the map and unpam parameter declaration. The BNF expects that the map and unmap param declarations follow the message/procedure list, but the rules in the textual part state that they precede the list. Interesting thing is that the code examples are written according to BNF.

Tags | No tags attached.

Relationships

related to | 0005417 | closed | Ina Schieferdecker | Support of parametrized map/unmap operation for full dynamic mapping
related to | 0002105 | closed | Ina Schieferdecker | address should also be bind to port type
related to | 0005924 | closed | Ina Schieferdecker | What should happen when parameter list is present in port type, but not used in map operation
related to | 0005925 | closed | Ina Schieferdecker | in case of global unmap - is param list allowed or not?

Attached Files | CR5923.docx (19,822) 29-09-2011 11:53 http://oldforge.etsi.org/mantis/file_download.php?file_id=2571&type=bug CR5923-v2.docx (8,267) 29-09-2011 12:33 http://oldforge.etsi.org/mantis/file_download.php?file_id=2572&type=bug

Issue History
Date Modified | Username | Field | Change
22-08-2011 15:23 | Andrus Lehtmets | New Issue |
22-08-2011 15:23 | Andrus Lehtmets | Clause Reference(s) | => TTCN-3 Edition 4.3.1: Core language
22-08-2011 15:23 | Andrus Lehtmets | Source (company - Author) | => Elvior
27-09-2011 12:04 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 12:08 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
27-09-2011 12:08 | Gyorgy Rethy | Status | new => assigned
27-09-2011 12:08 | Gyorgy Rethy | Target Version | => Edition 4.4.1
28-09-2011 12:37 | Ina Schieferdecker | Note Added: 0010270 |
28-09-2011 12:37 | Ina Schieferdecker | Note Added: 0010271 |
28-09-2011 12:37 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jacob Wieland - Spirent
28-09-2011 12:54 | Jacob Wieland - Spirent | Note Added: 0010273 |
28-09-2011 12:57 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
29-09-2011 09:45 | Ina Schieferdecker | Relationship added | related to 0005417
29-09-2011 09:47 | Ina Schieferdecker | Relationship added | related to 0002105
29-09-2011 09:50 | Ina Schieferdecker | Note Added: 0010289 |
29-09-2011 11:31 | Ina Schieferdecker | Note Edited: 0010289 |
29-09-2011 11:38 | Jacob Wieland - Spirent | Note Added: 0010294 |
29-09-2011 11:53 | Ina Schieferdecker | Note Edited: 0010294 |
29-09-2011 11:53 | Ina Schieferdecker | File Added: CR5923.docx |
29-09-2011 11:53 | Ina Schieferdecker | Note Added: 0010295 |
29-09-2011 11:54 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jacob Wieland - Spirent
29-09-2011 12:33 | Jacob Wieland - Spirent | File Added: CR5923-v2.docx |
29-09-2011 12:34 | Jacob Wieland - Spirent | Note Added: 0010297 |
29-09-2011 12:34 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
29-09-2011 15:32 | Jacob Wieland - Spirent | Relationship added | related to 0005937
29-11-2011 12:54 | Ina Schieferdecker | Note Added: 0010390 |
29-11-2011 13:05 | Ina Schieferdecker | Status | assigned => resolved
29-11-2011 13:05 | Ina Schieferdecker | Resolution | open => fixed
29-11-2011 13:05 | Ina Schieferdecker | Fixed in Version | => Edition 4.4.1
29-11-2011 13:05 | Ina Schieferdecker | Status | resolved => closed
29-11-2011 15:51 | Ina Schieferdecker | Relationship added | related to 0005966
29-11-2011 15:51 | Ina Schieferdecker | Relationship deleted | related to 0005966
29-11-2011 15:52 | Ina Schieferdecker | Relationship deleted | related to 0005937
29-11-2011 15:53 | Ina Schieferdecker | Relationship added | related to 0005924
29-11-2011 15:54 | Ina Schieferdecker | Relationship added | related to 0005925

Notes

(0010270)
Ina Schieferdecker
28-09-2011 12:37

Proposal to change to
type port PortTypeIdentifier message "{"
[ address Type â€œ;â€ ]
{ ( in | out | inout ) { MessageType [ "," ] }+ ";" }
[ map param "(" { FormalValuePar [","] }+ ")" ]
[ unmap param "(" { FormalValuePar [","] }+ ")" ]
"}"
Procedure-based port:
type port PortTypeIdentifier procedure "{"
[ address Type â€œ;â€ ]
{ ( in | out | inout ) { Signature [ "," ] }+ ";" }
[ map param "(" { FormalValuePar [","] }+ ")" ]
[ unmap param "(" { FormalValuePar [","] }+ ")" ]
"}"

(0010271)
Ina Schieferdecker
28-09-2011 12:37

Please check

(0010273)
Jacob Wieland - Spirent
28-09-2011 12:54

This was already solved in 5417, but must be merged with solution for 2105, as well.
Basically, to allow any order, it must be:
type port PortTypeIdentifier message "{"
{ address Type â€œ;â€ |
( in | out | inout ) { MessageType [ "," ] }+ ";" |
map param "(" { FormalValuePar [","] }+ ")" |
unmap param "(" { FormalValuePar [","] }+ ")" }
"}"
Procedure-based port:
type port PortTypeIdentifier procedure "{"
{ address Type â€œ;â€ |
( in | out | inout ) { Signature [ "," ] }+ ";" |
map param "(" { FormalValuePar [","] }+ ")" |
unmap param "(" { FormalValuePar [","] }+ ")" }
"}"

(0010289)
Ina Schieferdecker
29-09-2011 09:50 (edited on: 29-09-2011 11:31)

In 5417 it was proposed the wrong way ... anyhow, it would ease matters so that any order is more convenient

(0010294)
Jacob Wieland - Spirent
29-09-2011 11:38 (edited on: 29-09-2011 11:53)

in the last proposal for 5417, it was proposed with the wrong order. Anyway, I just saw that the map/unmap lines miss the ";" after the ")"

(0010295)
Ina Schieferdecker
29-09-2011 11:53

Please check

(0010297)
Jacob Wieland - Spirent
29-09-2011 12:34

updated so that all declarations inside port attributes can be any order, also address

(0010390)
Ina Schieferdecker
29-11-2011 12:54

Added the restrictions: "In addition to the general static rules of TTCN 3 given in clause 5, the following restrictions apply: - At most one address type should be bound to a port type - At most one map parameter list should be defined for a port type - At most one unmap parameter list should be defined for a port type "