Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005923Part 01: TTCN-3 Core LanguageEditorialpublic22-08-2011 15:2329-11-2011 15:52
ReporterAndrus Lehtmets 
Assigned ToIna Schieferdecker 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.4.1 (published 2012-04)Fixed in Versionv4.4.1 (published 2012-04) 
Summary0005923: BNF (rules 50 and 58) in appendix A and port type definition chapter 6.2.9 do not match
DescriptionBNF (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}
                                                        ")"]
Additional InformationIna: 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.
TagsNo tags attached.
Clause Reference(s)TTCN-3 Edition 4.3.1: Core language
Source (company - Author)Elvior
Attached Filesdocx file icon CR5923.docx [^] (19,822 bytes) 29-09-2011 11:53
docx file icon CR5923-v2.docx [^] (8,267 bytes) 29-09-2011 12:33

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

-  Notes
(0010270)
Ina Schieferdecker (reporter)
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 (reporter)
28-09-2011 12:37

 Please check
(0010273)
Jacob Wieland - Spirent (reporter)
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 (reporter)
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 (reporter)
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 (reporter)
29-09-2011 11:53

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

 updated so that all declarations inside port attributes can be any order, also address
(0010390)
Ina Schieferdecker (reporter)
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
"

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker